If not Access.... what to use?

[EKC]

Im very tired of Access little bugs (after developing in
it for 10years). I want to try another product that does
the same thing but that I have more control over. Got any
suggesttions? Some GUI program w/some SQL program?
PowerBuilder? MySql? C++? Visual Basic? I distribute
my database; I want to do so more professionally (without
having to have Access on the PC; and I dont want to use
Access runtime).

 

[James Goodman]

If you are used to Access & VBA, then the simplest to move into will be VB6.
However, VB6 is a fairly old technology & microsoft are pushing .NET pretty
hard. ASP could be another consideration & is great for wide-used corporate
applications.

..NET is at first very different to VB6 & can be a little daunting, but I
think it is an improvement. You can develop some reasonable db applications
connecting to pretty much any datasource & have to write almost no code.
Once you get used to the layout of things in .NET, I reckon you can develop
applications at pretty much the same speed as Access, which you could not do
in VB6. This is great, because one of the things I always disliked about VB6
was the extra time it took to create certain types of db applications which
were very easy & fast in Access. Hopefully, with the evolution of .NET this
will become a thing of the past.

Something very annoying about .NET is the inability to make changes to your
code during debug, something I sorely miss. It also requires the .NET
library installed on the host pc, which is approx 21MB...

 

[Albert D. Kallal]

I reckon you can develop

applications at pretty much the same speed as Access, which you could not do
in VB6.

Gee, that would be a surprise! One of the things why ms-access is so good is
due to the bound forms, and the events, and all of the properties you get
with a form. VB forms never had stuff like on-insert, before update, after
update etc.

Heck, just dropping a combo box onto a form the wizard tends to run circles
around those other IDE's.

In fact, a common need is to make a grid of data, and place a button on that
gird to open a form with details. In ms-access,that is ONE line of code.
And, take a look at the grids you can make in ms-access with very little, if
any code. Check out:

http://www.attcanada.net/~kallal.msn/Articles/Grid.htm

I see little, if anything in products like .net, or VB6 that even remotely
comes close to the forms model that ms-access has. I would say for most data
centric products, access is still going to be about 3 times as productive.
That means a $9000 project in ms-access is going to cost about $30,000 in
..net, or VB for that matter.

I could probably write about 100 pages as to why a product like ms-access is
going to be more productive. Amazing things like having a on-open event that
lets you cancel the form BEFORE it loads is really amazing. Then, once the
form loads, you use the on-load event for code, and setup stuff. This
division of the form load into two events is brilliant, and to cancel form
loads in VB is kind of a hassle (the other IDE's mentioned miss this
division. The combo box has a not in list event, and is multi-column (again,
to get this functionally takes a lot of code in other platforms). Lets not
forget the incredible sub-forms! You can read why the are so good here:

http://www.attcanada.net/~kallal.msn/Articles/fog0000000005.html

It is true that the forms in ms-access are far more complex then the simple
and lame VB forms. This makes VB a lot easer to learn and master then
ms-access. However, once a developer learns about the additional properties
and events for a ms-access form, then they are hard to touch in terms of
productivity. (there is least double the amount of stuff you have to learn
when using ms-access forms).

As always, it is the right horse for the right course. We could not, and
would not try and write a game in ms-access. So, it really depends on what
application one is writing. For sure in area .net is far better. However,
for data centric applications VB, or vb.net are not like say 30% range close
here...but are SEVERAL ORDERS of magnitude behind ms-access when it comes to
building applications that work with crud. (crud = create, read, update,
delete).

You can use autoCad to make drawings, or you can try and do the same thing
in VB.net. I would be quit silly to suggest that VB.net is as good as
autoCad for drawings. I suppose with a tedious amount of work, VB.net could
be come as good as AutoCAD for drawings.

The same goes for data centric applications. .net is not a database
development system. While it certainly very good at handling data, but it is
no more of a database RAD tool then it is a autoCad drawing program. It is
not a RAD tool anywhere remote close to ms-access..

 

[Dave Ruhl]

I've used FoxPro/Visual Foxpro for most of the past 16
years and had to switch to Access due to a job change.
They each have some nice features that the other lacks,
but overall I think Visual Foxpro is more advanced. It
has been around much longer, objects have many more
properties that can be set (instead of writing VB code
for them), and it's much easier to create stand-alone
apps (you just have to include a couple of small DLLs
with the .EXE file). Compiling and making the EXE is WAY
faster than Access, and the distributed file is much
smaller. The Access app I'm currently working on has an
MDE that is 18MB. The last VFP app I worked on was 3
times as complex yet the EXE was only 1.5MB. If you're
looking to change, VFP is a nice alternative. The only
downside is that VFP jobs are harder to find than
VB/Access. Also, I also prefer to work with SQL Server
back-end databases - using Access or VFP as the front-end
only.

Good Luck!

 

[Albert D. Kallal]

I've used FoxPro/Visual Foxpro for most of the past 16
years and had to switch to Access due to a job change.
They each have some nice features that the other lacks,
but overall I think Visual Foxpro is more advanced.

I used to be a FoxPro developer. I moved on before the Visual versions came
out. In looking at the Fox product, it is likely one the of best kept
secrets in the Microsoft farm. You get great RAD abilities, OO if you need,
and that great distribution ability. For "my" applications that need
distribution, I still seriously consider using VFP. I just never got around
to using the product, and that is my loss for sure!

The Access app I'm currently working on has an
MDE that is 18MB.

Gee, that does sound large. My current medium sized application has:

number of Forms = 161
number of Reports = 72
number of tables (total) = 63
number of tables (user) = 54
number of modules = 23
number of Queries = 180

lines of code in Modules = 8670
Lines of code in forms = 16342
Lines of code in reports = 2258

total lines of code = 27270

(I have a little program that I run to gen the above stats)

The above application as a mde is JUST over 5 megs. So, if your front end
is 18 megs in size, perhaps either there is graphics behind some forms?, Or,
you just simply have a large application!

 

[Dave Ruhl]

Hi Albert, I think my app is just about as big as the one
you described, but I only have linked tables (to SQL
Server) so there is no data in the source tables. The
source file is about 80MB after compacting. I inherited
the project at 117MB source with 11MB MDE. I have
rewritten most of the code and removed lots of
duplication, and I've added tons of forms and reports.
The result was a smaller source but larger MDE. I'm just
curious as to why your MDE would be so much smaller ?

Forms = 150+ (including subforms)
Reports = 150+ (including subreports)
Queries = 150+
Linked Tables = 200+
Modules = 15 (lots of public functions & subs)

 

[Tony Toews]

Gee, that does sound large. My current medium sized application has:

number of Forms

FWIW my one clients FE has about 2.5 to 3 times as many objects as
yours and is 18 Mb MDE in both A97 and A2000. Which roughly
correlates to yours.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Albert D. Kallal]

Gee, looking at your numbers, you have about double the reports..but as you
say, somewhat in the same ball park as what I have. Not a real huge increase
over my numbers.

Your number of tables is much larger, but in both of our cases, we are
talking about data tables that reside else where. Those numbers I posted
are for a mde, and is of course linked to a back end. (so, either way, the
number of tables is not going to be the issue for the "size" of the mde).

My front end is only just 7 megs, and that comes out as a 5 meg mde.

There is most certainly something different going on here. My guess is that
you have some logo, or are using background images for the forms. I stick
100% to the boring battleship grey. However, when you start using Terminal
Server, or just having lots of forms, that boring grey really pays off in
terms of keeping the application down to an amazing small size.

My bets are you have graphics, or some background stuff you are using for
your forms. I would consider getting rid of them.

If you look at Tony's response, he is also coming up with similar numbers to
my size.

If your application DOES NOT have any graphic, or backgroup image stuff,
then I would consider trying a de-compile. (ONLY do this on a copy in case
it don't work).

You can read more on the de-compile option here:

http://www.granite.ab.ca/access/decompile.htm

If you read the above, there is some amazing testimony as to MAJOR reduction
in the mdb size. I don't think this applies to the resulting mde file size.
However, if you don't have backgrounds, or logos in your application, then I
would certainly give a de-compile a try.

I certainly use de-compile on my stuff.

 

[Dave Ruhl]

Thanks, I will try a decompile on a copy. All of my
images are 'Linked', not embedded, and they only amount
to 300K or so. As I said before, I inherited this app
and I've re-written just about all of it. The size isn't
a problem, but it does take a long time to make the MDE
(5 minutes or so - I'm used to 30 seconds to make an EXE
in Visual Foxpro). Thanks again for the tips.

 

[Albert D. Kallal]

Gee, it takes less then 20 seconds on my slow 600mhz notebook to create that
mde. This "time" is for a2002, or a97. They both take about the same amount
of time.

So, we are talking about a 8 meg front end, and a 6.8 meg back end for
a2002.

As for linked backgrounds, there is still some overhead used. If you are
talking about linked images each record, then the image issue is NOT a
problem. I would not use images for the backgrounds.

I would suggest you make a test mdb, and remove all background images from
those forms. they make a real mess of things...linked or not. (if you have
lots of forms...just write a loop to remove the background image.

I am not sure why you are seeing such long mde build times, and also such a
large mdb front end. On my notebook that has limited processing and not much
ram (192 megs), that above mde takes only 20 seconds to create. Even if it
was larger, say 16 to 20 megs, we would still be likely well below one
minute. Of course, with newer and more modern hardware, those mde build
times for a large mdb would likely be much less time then my notebook.

 

[Adam]

Hang on a minute...do you think that by walking away from
Access that you are going to solve problems? Wherever you
go, those bugs will be waiting for you!! Little ones and
big ones!!

I've been doing Access dbs now for nearly three years, and
yeah...some things have been a pain in neck...but wait a
minute...in 2000 I took out a computing degree and I
remember those awful examinations and assignments...in
C/C++(sniff...), Cobol, Eiffel, SQL, VB, and Java...how I
stayed up all night long to get them working properly. In
comparison with these experiences, the problems I get with
Access are nothing.

So at the end of it all you'll get your pros and cons with
all of them. And having got this far, I'm sticking with
the market leader in small scale environments.

Good luck

Adam
Getting Stronger and ...Wiser

 

[Brendan Reynolds]

Have to agree with Albert here - even though there are many things that I
like about VB.NET, in my experience developing database applications in
VB.NET takes much longer than developing database applications in Access,
and requires writing much *more* code, not less.

 

[Brendan Reynolds]

This is my experience also. Yes, Access does drive me crazy sometimes - but
no more so than any other tool I've ever tried.

I do think a distinction needs to be drawn between custom apps and
'off-the-shelf', 'shrink-wrap' apps. If you need to send out CDs and let
users without retail Access install the app and the runtime themselves,
rather than going on-site for the initial installation, the runtime is a
PITA, and I followed Dave's comments about VFP deployment, elsewhere in this
thread, with interest. But for custom apps, where you can do the initial
installation yourself (or if you can get away with specifying retail Access
as a minimum requirement) Access is hard to beat.

 

[Dave Ruhl]

The few images I link to are for graphic 'buttons' and
they are something I added to the app, so they were not
in the app I inherited, which still took a long time to
make the MDE. I'm on Access 2002, Windows 2000, P3
1100MHz, with 1GB RAM and it takes 5 minutes to make the
MDE. It takes just as long on a Windows XP, P4 2GHz,
256MB RAM. I'm going to try the decompile and a few
other things to see if I can identify the problem.

 

[Dave Ruhl]

That's true, you will find bugs and annoyances in just
about any developement tool you work with, and I must say
that the problems I've had with Access have been easier
to work around - especially with the help I find here on
this forum.

 

[Dirk Goldgar]

The few images I link to are for graphic 'buttons' and
they are something I added to the app, so they were not
in the app I inherited, which still took a long time to
make the MDE. I'm on Access 2002, Windows 2000, P3
1100MHz, with 1GB RAM and it takes 5 minutes to make the
MDE. It takes just as long on a Windows XP, P4 2GHz,
256MB RAM. I'm going to try the decompile and a few
other things to see if I can identify the problem.

I haven't heard of this affecting the making of an MDE, but make sure
that Name Autocorrect is turned off in the Options dialog.

 

[Tony Toews]

If you read the above, there is some amazing testimony as to MAJOR reduction
in the mdb size. I don't think this applies to the resulting mde file size.

Yes decompiling does shrink the MDE size as well.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Tony Toews]

Yes decompiling does shrink the MDE size as well.

In A97 anyhow. Not sure about A2000 and newer.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm