Re: Advice Needed...

I'm definately not the first person. The problems are extensive but
basically you're not making a real app. With VB6 you have to work to add
the required functionality. In access you have to work to remove a lot of
functionality in an attempt to make it look like a real app. The forms
just look plain ugly and outdated because they made all their own
controls.

Really? I've always thought VB6 forms suffered from that. Besides, in
either case, you can always load in custom controls, so I don't see that as
a huge issue.

This also eliminates the possibility of using APIs on the controls because
they are not real windows controls.

Such as? I've never seen a need to use an API on a control...for anything.
It's probably cuz I'm a DB person; I don't need my controls to do funky
things, I need them to work. The Access controls do that far better than
the built-in VB controls in my experience.

Then there's the instability of the backend and problems with customers
having different versions.

What instability? The only real issue is the problems when an app shuts
down unexpectedly. I'll admit, they could've done a bit better of a job
with that in Access. As for compatibility, they're all backwards
compatible...the newer ones are seamless and transparently backwards
compatible. As long as you're not looking for forwards compatibility, it
should be a problem.

Oh but they do...they could choose to go the same route they did with
VB.NET and break compatibility with all former applications, forcing all
existing code to be re-written. But that would be a dumb idea, wouldn't
it? ;-)

They could not do that and you know it. It is a different situation to
what has happened with dot net and your analogy doesn't quite hold water.

That's not the way many of us see it.

With VB6 you can still develop apps in vb6 that will run on all OSs.

And cross your fingers and pray to any and all divinities if you're trying
to run it on Vista...or so I hear. :-)

A better analogy would be if they implemented a new API structure in
windows but kept the old one also, which is exactly what they do all the
time.

Ah, but in VB.NET, they didn't keep the old one also, did they? They simply
trashed the old one and told you to re-write with the new structure.

I should be able to create a table called Person with FirstName, LastName
etc and then create Staff and Customer tables that inherit from Person. I
haven't ever used it so not sure how well it would work in reality.

I've never heard of database tables supporting that functionality...though
admittedly, most of my experience is with the MS products. That sounds like
something that should be the work of an OO language, not a database itself.

Have a read of this one, it looks like they tried to have non-zero based
arrays but decided against it for very good reason.
http://www.panopticoncentral.net/archive/2004/03/17/290.aspx

Thanks for that. I at least understand the thought behind it now, though
given that C# and VB.NET go through so much else, being managed languages, I
wouldn't have thought the performance hit (or size hit, if they'd followed
Karl's suggestion in the commentary) of a non-zero array would really be
that big of an issue.

I would prefer 1 based arrays myself but am more than happy to have all
zero based arrays if that means we have consistancy. I agree it's a little
confusing going from 0 to 30 but this is the same with any list of items.
The first item is index zero, the second is index 1 etc.

True enough. Personally, I almost never use anything but 0-based arrays,
but it certainly IS convenient at times to have the choice.

I'm suprised a third party hasn't released a better upgrade tool. It
wouldn't be hard to do and would be popular and could be fairly
expensive.

Yes, it would be EXTREMELY popular, I'd imagine.

Could be a good project for those on this group.

We should ask Rick Rothstein to do it. He'll manage it in just one line!
;-)



Rob


.

Loading