MSAccess 2000 Runtime

1) Runtime is not a full Access. Some features are not
available in Runtime.

You can test your app in runtime mode, before you make a package. Just run Access with /runtime option. I.e.:

"C:\Program files\Microsoft Office\Office\msaccess/exe" /runtime "C:\My documents\mydatabase.mdb"


2) If everything works fine, it means that there should be another reason of your problems.

I.e. your applications causes a runtime-error error, but you don't handle this error. (In runtime mode you cannot debug your code and find an error point!)
Some errors are not dangerous, while other may crash down your application. So, you should add an error handling to every your procedure and function.

Hint: Try to run an example database (Northwind.mdb) on the test machine. Does it work or not?


3) Finally, your problems may be caused by wrong/incomplete Runtime installation.
Try to create any simple, small application. Just one table, one form, etc. Then, try to run this application on the test machine.
This will help you to decide if the problem is with the machine (runtime) or with your application.


4) Check out the file access permissions. Maybe some files
have read-only attribute or maybe user hasn't got a permission to modify the file?


Here are some ideas. HTH

Need help? - Just @skme!

Hey there krzycz ,


I have already tested the app using the runtime switch u mentioned and everything runs as it should.

I do have error handlers in my code the problem is that the code never ever gets executed so the error handler is nerver loaded.

Rights and permissions are not the problem either as i have full admin access to both the devlopment and test environments.

Good idea with NWind, ill try it and get back ASAP but it
takes approx 2hrs to create the package.
Is that normal ?

Don't create a package!
Just copy NWind.mdb to the test machine.
Runtimne is already installed, so you don't have to create a whole package. Especially, don't include a Runtime in the package!

2 hrs? Oh, God! It's absoluetly too long!
It takes only several minutes on my old machine (Pentium 200).
Usually, it's about 15 mins to create a package and to burn it on CD-RW.

ok so i DONT have to recreate the package each time i make a change to the app?

Not exactly.

Hmmm, if you make some little changes, you don't have to recreate a package. Just copy a new version of MDB/MDe to the user(s) machine(s), replacing the old version.

Of course, we talking about splitted database - there is an application file and data file(s). So, in many cases you can just replace the application file with the new one.

But if you add some ActiveX controls to your app or references some external libraries, then you should recreate a package, because these new components may be not installed on user machine(s).
They should be installed with your new package.

However, since you've installed a Runtime on user machine(s), you don't have to include Runtime in your package anymore. They already have Runtime on their machines.

Well, it's a good idea to create a full package from time to time. I.e. every time you release a "milestone" build of your application.
But if you only patched some bugs, there is no need to recreate a full package. Just distribute a new version of main mdb/mde file.

ok i  grabbed the nwind db and created a new package (just to be on the safe side) but when installing the runtime i get this :
The dynamic link library MSDART.dll could not be found in the specified path
c:\winnt\;.c:\winnt\system32\;.c:\winnt\system\;.E:\oracle\ora8 blah blah blah loads more install paths.

it looks like my test machine is the problem - ????

if i ignore install completes but of course i never created an autoexec for startup so all i have is a blank screen!!

if i create an autoexec and just copy in the .mdb straight to the test machine, will it work ?

ok so northwind seems to run ok as a runtime version
even if i got the previous error.

so i suppose this means my code is wrong ?

Probably yes.
Sad, but true. ;-)

on further testing i have found that i procedure seems to run about half way through and then crashes. this procedure calls 2 other sub procedres perfectly before the app crashes out.


this is really drivin me nuts!!

does anybody have an idea as to what is happening ?

i have convinced the client to run with a full retail copy.

I know this is a long time after the problem, but what, Datrias, was the reason that run-time woudn't work?  We are having a similar problem with one of our applications and we don't want, much less can afford, full versions of MSACCESS on user's computers.

Sorry, I never solved this problem and havent had to use the Runtime since.

I also had this problem and have solved it, although this may not help you.  In my code I was using dir(strFileName) to check to see if a file exists.  When I checked the program on a test machine I got the same error as you.  I checked the contents of strFileName and found out it was d:\path whereas the test machine with Access Runtime on it does not have a D drive or D drive was the CDROM with no CD in it.

I now use the following code to check if the path exists first:  (thanks Chris Rae)

Function DirExists(ByVal strDirName As String) As Boolean
    ' Chris Rae's VBA Code Archive - http://chrisrae.com/vba
    ' Code from the Deployment Wizard, passed on by Will Rickards.
    On Error Resume Next

    DirExists = (GetAttr(strDirName) And vbDirectory) = vbDirectory

    Err.Clear
End Function

thanks dom_cath -  your comment could prove very valuable!

This is how we debug problems in Microsoft Access Runtime now:

1.  We created a dummy integer variable "int_dummy" and set it equal to zero at the beginning of the procedure creating the error (any variable type and value would work).

2.  at various parts of the program, we change the value of the dummy value by incrementing it, and then writing it to an external text file, e.g.,

Open "c:\test.txt" For Append As #1
int_dummy = int_dummy+1
write #1, int_dummy
close #1

You can copy this block at various parts in the code.  When the program crashes, we check out the value in test.txt, and that tells us the last block that executed before the error (if the test.txt has the last value as 4, we know that the error is in between the fourth and fifth blocks of code above).

3.  We can hone in on the problem if necessary by moving the fourth block of code down a line, successively crashing the program until the last value is one less the previous value (in this case, three).

Then we know the problem occurred in the line immediately preceding the fourth block.

Also, if you are using the open command in the sub, you will want to use "FreeFile" function instead of #1.  Dim a variable called FileNumber, and then use the following block for your auditing points:

   FileNumber = FreeFile
   Open "c:test.txt" For append As #FileNumber
   int_dummy = int_dummy+1
   Write #FileNumber, int_dummy
   Close #FileNumber

You should start putting this block immediately after your variable declarations, and before any signficant code.  That way you can tell if the code itself is causing a crash (test.txt would be empty).  If its not, there's nothing wrong with this block and the problem must be something else.

It's tedious, old-fashioned, and time-consuming, but it works.

Kevin

Hi Again,

The other time I got this error was when I had split my tables and had the database running in a multi-user environment.  The tables were stored on a network share that I had accidently left as ready only.  The first runtime opened the database correctly albeit in ready only but any second runtime had a problem as it could not leave or alter the ldb file and came up with this error.

If the tables are on a network share make sure the network share has write access for the users who use the database.