2007 Runtime Directory

A

Arturo

When setting up the 2007 runtime version, what do you need to know to create
a directory on a network server? Can you just create one or do you need to
know about the network you would be working with? Any information you have
would help.

Thank you.
 
K

Klatuu

The runtime should not be installed on a network. It should be installed on
each user's workstation that is going to run an Access application. Each
user should also have their own copy of the accdb file.

What you are trying to do will create an environment that will be very, very
slow and make your network jockeys very mad when they find out how much
unnecessary traffic you are putting on the network.

The only file that should be on the network is the back end half of a split
database. It contains all the data that the users will be sharing.
 
A

Arturo

True. I know from experience that is correct. In fact, I am currently
developing a program and both components are on the server. Slow is the word.
At this time it is necessary. However, I do need to develop a script for that
one so that each time they click on the icon (a shortcut to the script); it
will load a copy onto their computer. (If you have that I will take it.)

But, let me clarify this one a little more. I am setting up the front end on
the user's computers. My question was in reference to the back end that will
go on the network server. That is what I need to know about.

On the other hand, the scenario I mentioned above would be great for solving
this problem. How about this? Set up the runtime version on the server,
front-end and back-end. Then create a script on the server with a shortcut to
it on the user's computer. When clicked, the front-end would be copied to
their desktop. This way any changes made to the front-end would be made on
the server and eliminate the need to go to each user's computer.

As far as the workload, on this endeavor, almost all of it is done locally
on the user's computer. When starting the day, they pull their data into
their database and work with it. At the end of the day, edited work is
updated, new work is appended.

Thanks.
 
K

Klatuu

You don't need the runtime on the server. Access is not a client server
application. It is a file server application. All the processing takes
place on the client machine. No part of Access runs on the server. Even
when a front end is on a server, the application actually runs on the client
computer.

Database engines like SQL Sever or Oracle are different. They do have
processing on the sever. That is one of the things that makes them faster.
When you request a record from a client sever database engine, the processing
to select the record occurs on the sever and only the requested record is
returned. That means only the request and the one record travel accross the
network.

Because Access (Jet database engine) is a file sever engine. When you
request a record, Every record in the table or query is transfered accross
the network and only the requested record is kept.

I don't have a script example for you, I use the front end updater method.

All you need is .bat file to copy the file and then launch your application.
 
K

Klatuu

I found one.

Copy "O:\Installation\RealPro Install\Update MDE\*.*" "C:\Program
Files\RealPro\"
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "C:\Program
Files\RealPro\REALPRO.mde" /runtime
 
A

Arturo

Thanks again. One more question. What if I place
file a.mdb (the be), and file b.mdb (the fe),
on G: Drive and I want to copy b.mdb to
C:\Test, have it overwrite the existing file,
and open the new copy for use?

How would I accomplish that?
 
K

Klatuu

Copy "G:\b.mdb" "C:\Test\"
"C:\Program Files\Microsoft Office\OFFICE12\MSACCESS.EXE" "C:\Test\b.mdb"

You can get more info on the copy command by click Start, run from the
windows menu and typing in cmd
When you get the DOS command box, type in
Help copy
 
A

Arturo

I tried that and get a Windows Script Host message.
It says "Expected end of statement" and the location
is here b.mdb"(HERE)"C:\Test\"
I put a comma in there and I get a the a new message.
It says "Expected statement" and it is now at
Line 2 Char 1.
Can you help?
 
K

Klatuu

Post the contents of the bat file exactly as you have it in your file. I
can't tell from this.
 
A

Arturo

Guess what? I created a Bat file, copied the code into
it and it worked. It takes about 45 seconds to open.
I would assume that is a result of the network, my
computer, and how much RAM I have. Or, is there
something else I can do?

Thanks.

Copy "G:\Storeroom Orders Log\Log.mdb" "C:\Test\"
"C:\Program Files\Microsoft Office\OFFICE12\MSACCESS.EXE" "C:\Test\Log.mdb"
 
K

Klatuu

The factors are
Size of file
Speed of network
Speed of your computer.

The only thing you can do compact and repair the file so it is as small as
possilbe.

Now, there is another solution that involves keeping version numbers for the
application in the front end and backend mdbs. If you can't improve the
perfomance to your satisfaction, we can discuss the alternative.
 
A

Arturo

I will see how it works out. Is there anyway to minimize
the DOS window that pops up. It is C:\Windows\
System32\cmd.exe?
 
A

Arturo

Tell me about the version numbers, please.

Klatuu said:
The factors are
Size of file
Speed of network
Speed of your computer.

The only thing you can do compact and repair the file so it is as small as
possilbe.

Now, there is another solution that involves keeping version numbers for the
application in the front end and backend mdbs. If you can't improve the
perfomance to your satisfaction, we can discuss the alternative.
Click to expand...
 
K

Klatuu

Okay first question was about hiding the command window. Use the vbHide
constant in the Shell command

Shell( "batchfilename", vbHide)

Now as to versioning.

You need a table in the back end database. It only needs one field and one
row. It should have a value that identifies the current version. I would
suggest it be a text field. For example:

tblServerVersion
CurrentVersion - Text

You would link that table to your front end.

Then in the front end mdb you will have a local table that would identical
except for the table name

tblClientVersion
CurrentVersion - Text

Now, if you have a form that opens when your application opens, you can use
that, if not, you need a form that is identified as the startup form or you
could use a function in a standard module and call it from a Macro named
AutoExec.

If an mdb has a macro named AutoExec, it will run when you open the
application. I will use that as an example. The idea is you compare the
version numbers from the be and the fe and if the fe version is less than the
be version, you shell to the bat file and quit the application; otherwise,
you open your startup form. Note, if you use this method, you don't identify
your startup form in the startup properties.

Public Function CheckVersion()
Dim varServerVersion As Variant
Dim varClientVersion as Variant

varServerVersion = DLookup("[CurrentVersion]", "tblServerVersion")
varClientVersion = DLookup("[CurrentVersion]", "tblClientVersion")

If IsNull(varServerVersion) Or IsNull(varClientVersion) Then
MsgBox "No Version Data Found", vbCritical
Docmd.Quit
Exit Function
End If

If varClientVersion < varServerVersion Then
MsgBox "This application is out of date" & vbNewLine & _
"Click Okay to Update your Application" & vbNewLine & _
"This may take a minutes", vbInformation, "Version Update
Required"
Shell("batchfilenamegoeshere", vbHide)
Docmd.Quit
Else
Docmd.OpenForm "StartUpFormName"
End If
End Function

Now, I use like 1.0 1.1, 1.2, etc. So I would start with 1.0 in both tables.

So when you make modifications to your front end and you want to deploy a
new version, you change the CurrentVersion field in the front end to 1.1 and
put the mdb in the update directory.

Then you open the back end database and change the Current Version to 1.1

Now when a user opens their existing mdb, it will still say 1.0, so when the
code runs, it will see the server says the current version is 1.1 it will
cause the batch file to run and the application will close. As soon as the
copy is complete, the batch file opens the application again, but now it is a
copy of the new 1.1 version and the startup form will open.
 
A

Arturo

I think I can do that or something similar. I appreciate your help.

Klatuu said:
Okay first question was about hiding the command window. Use the vbHide
constant in the Shell command

Shell( "batchfilename", vbHide)

Now as to versioning.

You need a table in the back end database. It only needs one field and one
row. It should have a value that identifies the current version. I would
suggest it be a text field. For example:

tblServerVersion
CurrentVersion - Text

You would link that table to your front end.

Then in the front end mdb you will have a local table that would identical
except for the table name

tblClientVersion
CurrentVersion - Text

Now, if you have a form that opens when your application opens, you can use
that, if not, you need a form that is identified as the startup form or you
could use a function in a standard module and call it from a Macro named
AutoExec.

If an mdb has a macro named AutoExec, it will run when you open the
application. I will use that as an example. The idea is you compare the
version numbers from the be and the fe and if the fe version is less than the
be version, you shell to the bat file and quit the application; otherwise,
you open your startup form. Note, if you use this method, you don't identify
your startup form in the startup properties.

Public Function CheckVersion()
Dim varServerVersion As Variant
Dim varClientVersion as Variant

varServerVersion = DLookup("[CurrentVersion]", "tblServerVersion")
varClientVersion = DLookup("[CurrentVersion]", "tblClientVersion")

If IsNull(varServerVersion) Or IsNull(varClientVersion) Then
MsgBox "No Version Data Found", vbCritical
Docmd.Quit
Exit Function
End If

If varClientVersion < varServerVersion Then
MsgBox "This application is out of date" & vbNewLine & _
"Click Okay to Update your Application" & vbNewLine & _
"This may take a minutes", vbInformation, "Version Update
Required"
Shell("batchfilenamegoeshere", vbHide)
Docmd.Quit
Else
Docmd.OpenForm "StartUpFormName"
End If
End Function

Now, I use like 1.0 1.1, 1.2, etc. So I would start with 1.0 in both tables.

So when you make modifications to your front end and you want to deploy a
new version, you change the CurrentVersion field in the front end to 1.1 and
put the mdb in the update directory.

Then you open the back end database and change the Current Version to 1.1

Now when a user opens their existing mdb, it will still say 1.0, so when the
code runs, it will see the server says the current version is 1.1 it will
cause the batch file to run and the application will close. As soon as the
copy is complete, the batch file opens the application again, but now it is a
copy of the new 1.1 version and the startup form will open.
--
Dave Hargis, Microsoft Access MVP


Arturo said:
Tell me about the version numbers, please.
Click to expand...
Click to expand...
 
Top