Crystal Reports Error - VB4/16

I see stuff like this happen over and over.  When you create your application on a Win95 machine, and run it on a Win95 machine all goes well, but as soon as it goes to a 16 bit platform (3.11), it pukes.

When the setup wizard creates your setup disks, there are some .dll's (I'm not sure which ones) that get packaged up, that don't run cleanly on a 16 bit machine.  I've beat MS up over this, and they've told me the best thing to do is to create the setup disks on a 16 bit machine.

I've also talked to some of microsoft's top programmers, and they too suggest creating the setup disks on a pure 16 bit machine if I want to run them in a 16 bit platform.

Personally, I have run into your problem above, and the best way around it is to create a 16 bit windows environment and then create the setup disks.  What I do is have both Win 311 and 95 on my one machine, and then I reboot into one or the other when I fire up my machine.

OK, I'll try that, but my whole point was to keep my Win311 platform free of a VB install (like my clients machine), so I could check that the Setup program grabbed everything it needed.

I have two hard-drives in removable cradles, one with Win95 and one with vanilla Win311. I just switch the disks before booting. So are you saying I will have to install VB4/16 on my Win311 platform, just to be able to build the setup disks?

This sort of defeats the purpose of wwhat I was trying to do. Now I wont know if the application will run on a machine without VB installed!

Any thoughts on this?

Rick

OK, I'll try that, but my whole point was to keep my Win311 platform free of a VB install (like my clients machine), so I could check that the Setup program grabbed everything it needed.

I have two hard-drives in removable cradles, one with Win95 and one with vanilla Win311. I just switch the disks before booting. So are you saying I will have to install VB4/16 on my Win311 platform, just to be able to build the setup disks?

This sort of defeats the purpose of wwhat I was trying to do. Now I wont know if the application will run on a machine without VB installed!

Any thoughts on this?

Rick

You have to build the setup disks on a 16 bit platform.  That's the key.  You need to be sure that all .dll's and driver files grabbed by setup are 16 bit only.  The Win95 ones are suposed to be cross platform, but they aren't bug free.

OK, here is what I did.

* Installed VB4/16 on my Win311 platform.
* Copied my VB project onto that machine.
* Went into VB and saved the project and made a new EXE file
* Still on the Win311 platform, ran the VB4/16 Setup Wizard to create new setup files.
* Ran the setup, and still had the same error.
* Interestingly, I even get the error when running the application from the VB4/16 Development Environment. It happens on the CrystalControl.Action = 1 statement.

This is really giving me problems! I have to get this going soon or  my client is not going to be very happy!! Such is the life of the Programmer!!

Could it be that I really do have a corrupt DLL? If so, any idea which one it might be?

Rick :-{

Error Code 20534
Error Detected by Database DLL

The "Error detected in database DLL" or "Database DLL is corrupted" error is most common to Crystal Reports 2.0 for Visual Basic and reports generated within it. Only very rarely is the database DLL actually corrupted. More often it is a case of either the DLL failing to load because a needed component cannot be found or that the DLL is being asked to do something it is not capable of.

If you are encountering this problem with a report originally created in the Visual Basic version of Crystal Reports the first place to look is the [Installable ISAMs] section of either the VB.INI, CRW.INI or your own application's INI. This section should appear as follows:



[Installable ISAMs]
Btrieve=C:\WINDOWS\SYSTEM\btrv110.dll
FoxPro 2.0=C:\WINDOWS\SYSTEM\xbs110.dll
FoxPro 2.5=C:\WINDOWS\SYSTEM\xbs110.dll
dBase III=C:\WINDOWS\SYSTEM\xbs110.dll
dBase IV=C:\WINDOWS\SYSTEM\xbs110.dll
Paradox 3.X=C:\WINDOWS\SYSTEM\pdx110.dll



Be sure to include all components listed, even if they are not being used. If you have upgraded to Access 2.0, the 110 suffixes are changed to 200 (ex: btrv110.dll to btrv200.dll).

Sometimes a change in the database which Crystal is not aware of will cause Crystal to ask the database DLL to do something not possible with the current data. This can usually be resolved by opening the report in CRW.EXE and using the Verify Database command of the Database menu.

Also, make sure SHARE has been loaded prior to Windows in the AUTOEXEC.BAT file. The statement should look like:



C:\DOS\SHARE.EXE /L:500 /F:5100



Finally, make sure the database files have not been left open by the application prior to running the report.

Also, please check to see if the following conditions have been met.



1.Can CRW find the files it needs?
•For Crystal 3.0.1.3 or later, add the following line to your CRW.INI file in the \WINDOWS directory to get a more descriptive error message:

DebugMode=Yes
•Place this statement as the last line in the [Crystal Reports] section. •For Crystal 4.0.x.5 or later, select the File|Report Options and check the option More Print Engine Error Messages •Running the report again will give you an indication of what file it cannot find or load.
2.In the \WINDOWS directory, ensure that you have a VB.INI file containing the Installable ISAM information. For information on what these lines should contain, download Document #4110 from our Fax on-Demand system. 3.If the machine is running on Windows 3.x, ensure that SHARE.EXE /L:500 /F:5100 is loaded before Windows gets loaded. 4.The DLL could be corrupted. This rarely happens, if it does, then the FileSize would display a 0. 5.Your application could be calling the database in the wrong order using the Datafiles property. 6.The database isn't in that directory anymore. 7.When running app over network where users load Windows from server, even if VB.INI is in WINDOWS directory on server, the 534 error will still occurs. In the setups where each user has his/her own private WINDOWS directory, the VB.INI must be copied there. 8.The database is being opened exclusively elsewhere.

Unfortunately dirkmartins answer was on the wrong track, and jamesfasnachts was also off-beam, but it did give me a hint that I was able to follow up on.

The real cause was very simple. When I developed the Crystal Report the mdb file was in my development directory (C:\VBAPPS\APPNAME), but when the application was installed the mdb file was going into C:\APPNAME, so all that was wrong was that it couldn't find the database (a better error message might have been helpful!).

The fix was to set the DATAFILES property in the VB code to point to the insatllation directory, to over-ride the design-time settings.

I have this fixed now, as I explained in my last comment. Avellaps comment is useful info, however.