Access 2000 Runtime or VB 6 (Access 2000 Developer)

Topic

New Reply

I’m not sure this is the right place to ask this question, yet apparently there is a lot of things I don’t know.
I’ve developed a prototype database application with modem communications for a client on their machine in Access 97. They seem happy with the design, logic and workings (speed) and now want to package it. Now I was wondering if anyone had any opinion on whether it is better to up-size it to Access 2000 and use the runtime version in the Access 2000 developer or convert it to Visual Basic 6?

Reply | Quote

Replies

How proficient are you in VB 6? If you aren’t familiar with all the differences between VB forms and Access forms and comfortable with creating equivalent functionality in VB, I’d suggest going to Access 2000 instead. But what do you mean when you say they want to “package” it? In either case, you’ll need the packaging and deployment wizard, even if you switch to VB. Otherwise, there is no guarantee the application will run properly on a target machine, and no license for any ActiveX controls you may have used.

Reply | Quote

Unfortunately, not very, I’ve been meaning to move there, yet so far my work has called for office, office, office. On thing though with the differences concerning VB, with each list box and combo box, would you need a separate data source for each one, as well as the form?
Package, as in create an install that the client can run and use. The package and deployment wizard is fine for both VB and Access 2000 as I have the developer version.
No license for the ActiveX controls in Access or VB? I believed the VB ones were licensed and in Access only using one extra which says no royalties needed.

Reply | Quote

Royalties have nothing to do with the licensing issue. The activeX controls that come with Office 2000 developer edition are redistributable because the developer edition gives you the license for them, but the activeX controls that come with VB 6 are only redistributable if you have the Professional version or higher. Unfortunately, just about everything you might want to do in VB to emulate the Access environment is going to require ActiveX controls.

Reply | Quote

I’m not sure I understand what you mean by “up-sizing it to Access2000”, other than the Access2000 runtime takes 80MB+ whereas the Access97 runtime is only about 10MB.

It would probably be easier to deploy a VB application. However, how long will it take you to redo it in VB? While there are many similarities, there are some big differences; does VB allow you yet to use subforms like Access does? You could conceivably have the Access2000 version ready to go tomorrow.

Reply | Quote

Upsizing: Converting the Access 97 database to an Access 2000 database.

redo in VB? That’s what I don’t know. I don’t have much experience in VB except from maintenance point of view. From the looks of it likely a fair amount of time. Yes from what you said, VB does not do Subforms the same way as Access. So I would have to find another solution. I have one, yet it is not as easy to implement.

Doing the Access 2000 version is the way I am thinking, yet I wanted some other opinions before I suggest it to the client as an option.

Reply | Quote

Unless you’re a good VB programmer, stick with Access. You need a bunch of ActiveX controls to (I’m including the ADO DataControl and the related combo and listbox controls in that group) to even begin to get the funtionality you have built into Access forms. VB 6 reports are closer than its forms to the Access equivalent, but they lack the flexibility and richness of Access reports. The learning curve to convert is fairly steep, even if you use a product like AccessToVB, which will still force you to go in and manually edit the code and the objects to make them work.

Reply | Quote

Well I’ve got VB 6 Professional and Crystal Reports Developer to use. So it’s a learning curve with both. Yet I can use Crystal with Access 2000 I think.

Reply | Quote

Why bother to use Crystal Reports if you’re using Access 2000? The Access report generator is superior.

Reply | Quote

Because I didn’t know how to make interactive charts and VB didn’t describe much usefulness with charts either.

It is only today that I considered an Access 2000 runtime approach, for the last week it has been only VB app.

Reply | Quote

If it exists as an Access 97 app already, then why do you want to convert to Access 2000 for distribution? Why not distribute as Access 97.
An Access 2000 runtime installation can take up to 150 MB on the target machine depending on its current configuration and make numerous changes.
An Access 97 runtime would very likely be less than 20 MB and perform fewer changes to the target machine.

Reply | Quote

Yes I read that as well. Unfortunately I only have the Access 2000 Developer Version, the client company has the professional version of Office 97. And I couldn’t justify the downgrade.

Reply | Quote

Charlotte have you used Crystal reports?
I use both Access and Crystal. Access report generator is easier to use. However I believe the possibilites available in crystal make it a much better report generator at the end.

Reply | Quote

No, my first time with crystal reports, yet I have a few friends who have and seem to know what’s what with it. Yes, that is what they informed me as well concerning charting.

Reply | Quote

I haven’t used the latest versions. It is in use in our office, but those who use it only do so when they’re using VB with no Access component.

Reply | Quote

If you have a chance then have a look at one of the later versions (I have version 8.0), it can perform numbers of things that Access reports can’t handle (or not without a lot of coding). You’ll probably also see that the developers of Crystal could do with looking at the development environment in Access – that in my opinion is rather nicer to use, specifically modeless property dialogs for the controls on the report.
Do your colleagues think that the reporting in Access is overall superior to Crystal Reports?

Reply | Quote

No, they aided in the origional plan, Crystal Reports Developer 8.5 on VB6. Just now time is becomming an issue and I suggested to the client yesterday that we create an Access/Crystal solution this time round, (as they are still figuring out what exactly they want the software to do) and the next version run a VB6/Crystal Solution.

One thing, is it true that you have to create a data control for each combo box and list box on a VB form?

Reply | Quote

If you want other than just a single column combobox with a different bound column that what shows in the list, then yes. Any combos that can be populated directly from the underlying recordsource of the form or from a values list don’t need separate data controls.

Reply | Quote

If time is an issue then just a pure Access solution can be implemented the fastest. Especially if the App already exists as Access 97 format. It should only take a few minutes to convert to Access 2000 format. As you say if the client doesn’t know what they want then an Access prototype can be developed much more rapidly then a VB prototype. (Watch the change from DAO in Access 97 to ADO in Access 2000 – needs project references altering).
I have never tried using crystal reports directly from an Access interface. I use crystal reports with C++ based interfaces, pulling data from an Access backend.

Reply | Quote

I only made once the experience of transforming an ACCESS application to pure VB. It took a looooooooooong time and the result was not 100% identical with ACCESS. Furthermore, on some destination computers the VB application did not work due to lacking files.
Since then I always stay with ACCESS and the standard runtime files. Only two things are important:

1. You need to know exactly about the difference between full ACCESS and runtime environment (see MS KB at microsoft.com and ACCESS ONLINE ENCYCLOPEDIA at http://www.unsoftwareag.com).
2. You need a better installer program (the PDW is a software cripple).

Reply | Quote

I guess I wouldn’t call converting from Access97 to Access2000 “upsizing”. To me, “upsizing” would be converting to SQL Server.

Who are your customers? That is, who are you packaging this for? Is it remote users of your client company, or is it just anyone? Obviously, Access 2000 is the cheapest way to go from your standpoint. Just make sure you have ironed out all the potential problems with using the runtime (I don’t know how familiar you are with it). Things that are easy to do from a full Access version can’t be done from runtime; like invoking the Linked Table Manager, or even printing from print preview mode!
Then, there is always the missing references problem that might rear it’s ugly head.

Reply | Quote

Remote users to the client company. I’ve looked up the doco on Access 2000 runtime on the MS website so I’m with you there. Yes and missing references can always be a problem.

Thanks for your reply.

Reply | Quote

Argh, I’m just starting to look at using the 2000 (or possibly XP) runtime as a number of our users have 97 or worse nothing, and comments like “even printing from print preview mode” are a little bit worrying

Is there anywhere that details ALL the differences?

Reply | Quote

Try article Q162521 (“Differences between Retail and Run-time Microsoft Access”) in the Microsoft Knowledge Base.

Reply | Quote

Thanks

I also found Q208730 which details similar for Access 2000

I’ll have to invest some time in working out how to get the best from the Knowledge Base, there is a LOT in there

Cheers,
Steve C.

Reply | Quote