Jim Lawrence
accessd at shaw.ca
Mon May 2 23:00:47 CDT 2011
Hi John:
Hmmm, I see your concerns.
The FE is not running from the RAM disk it is just loading from it and that
is quite a different thing. In most cases the FE, loads once a day, maximum.
The actual package runs on the individual stations. Of course the FE is
locked on the server when someone is working on it and so it should be.
I have had this working for years, on a product that was originally designed
in Access97 so that dates it. :-)
The only problem that the script had to resolve was when there are two
people trying to grab the FE from the server at the same time. Then the code
would wait a couple of seconds and tries again and keeps looping until
resolution or until 10 tries and then it fall through and it then fails. (I
used a piece of code from the original Norton's command apps called WAIT.)
Under normal conditions I have never had a failure.
But for some reason I have never used it with another client...the speed of
transfer from today's servers has always been more than acceptable to the
clients. It always does take a few moments for the user to actually log on
to the MS SQL Server data source anyway.
Jim
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Monday, May 02, 2011 7:11 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Store accdr File Locally or on a File Server?
Not so, if you are talking about loading the FE from the ram disk. At that
point you are sharing
the Fe which is bad news. Not to mention that the FE is locked while anyone
is in it making it
impossible to update with the latest version if anyone is in the Fe.
John W. Colby
www.ColbyConsulting.com
On 5/2/2011 9:55 PM, Jim Lawrence wrote:
> When loading a crucial file, from the server to all stations and given
that
> the transfer has to be fast, create a shareable RAM disk on the server
> (default is drive Z), assign the appropriate drive letter, make it just a
> little bigger than size of the FE (allowing room for expansion and
> improvements) and load the latest FE into the memory drive.
>
> For all the information you may need see the following:
> http://www.speedguide.net/articles/ramdisk-guide-131
>
> When workstations log in, the latest version of the FE is transferred
almost
> instantly especially if you have a GBit LAN.
>
> This makes the whole issue of whether to store the FE locally a moot
point.
>
> Jim
>
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darryl Collins
> Sent: Monday, May 02, 2011 5:30 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Store accdr File Locally or on a File Server?
>
>
>
____________________________________________________________________________
> ___________
>
> Note: This e-mail is subject to the disclaimer contained at the bottom of
> this message.
>
____________________________________________________________________________
> ___________
>
>
>
>
> Here is the VB Script. I cannot attach it as a vb script so you will have
to
> save it as a script. You need to have on the server the .mde template
file
> and the Version No in a separate .txt file. You save this script either
> under the start> programs or as a Desktop Icon. The users clicks on the
> script to access the database FE. The script does all the work and call
MS
> Access (or the runtime). I usually change the VB Script icon to something
> useful for the users. Anyway, this should get you close to what you need.
>
> cheers
> Darryl
>
>
> '
>
****************************************************************************
> ************************
> ' Command line parameters.
> ' Parameter 1 : Application name. Excludes .mde extension.
> ' Written as args(0) to applicationName.
> ' This is also used for deriving paths.
> ' Ensure that this is identical for the script to run.
> '
> ' The script will test the version number in the version.txt on the client
> against
> ' the server version number in the version.txt.
> ' If the version is different it will copy the server version to the
client
> along with
> ' the version.txt file. If it is the same then it will run the client .mde
> ' Note : 'IT IS&O Client Integration Services' has required that any other
> files to be copied to
> ' the client be scripted separately in the routine
> 'copyOtherSpecifiedFiles()' at the end of the script.
> '
> '
>
****************************************************************************
> ************************
>
> Dim FS, FileStream
> dim sourceFullFileName, sourcePath, destinationPath, applicationName,
> intParCount
> dim sourceTxtVersionFile, destTxtVersionFile
> dim copyTheFile
>
> Set FS = CreateObject("Scripting.FileSystemObject")
> Set objShell = WScript.CreateObject( "WScript.Shell" )
>
> call launcher
>
> Set objShell = Nothing
> set FS = nothing
>
> sub launcher()
> on error resume next
> set args=wscript.arguments
>
> applicationName = args(0)
> sourcePath = "\\MyServer\MyFolder\MySubFolder"& applicationName& "\"
> destinationPath = "C:\Program Files\INT\"& applicationName& "\"
>
> ' Read the version text files and compare them.
> if FS.fileexists(destinationPath& "version.txt") then
> destTxtVersionFile = GetFile(destinationPath& "version.txt")
> sourceTxtVersionFile = GetFile(sourcePath& "version.txt")
> copyTheFile = not (destTxtVersionFile = sourceTxtVersionFile)
> else
> copyTheFile = true
> end if
>
> if (FS.fileexists(destinationPath& applicationname& ".mde") = false)
then
> copyTheFile = true
>
> if copyTheFile then
> FS.CopyFile sourcePath& applicationName& ".mde", destinationPath
> FS.CopyFile sourcePath& "version.txt", destinationPath
> copyOtherSpecifiedFiles
> end if
>
> openFile:
> ' Run the mde.
> ' Need to update this path if running OFFICE 2007+ (Office12)
> progToRun = "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
> objShell.Run Chr(34)& progToRun& Chr(34)& " "& Chr(34)&
destinationPath
> & applicationName& ".mde"& Chr(34)
> end sub
>
>
> 'Read text file
> function GetFile(FileName)
> If FileName<>"" Then
>
> on error resume Next
> Set FileStream = FS.OpenTextFile(FileName)
> GetFile = FileStream.ReadAll
> End If
> End Function
>
> ' Copy other files as specified.
> function copyOtherSpecifiedFiles()
> end function
>
'---------------------------------------------------------------------------
>
----------------------------------------------------------------------------
> -----
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jm.hwsn
> Sent: Monday, 2 May 2011 11:39 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Store accdr File Locally or on a File Server?
>
> I've heard about this and I know it's the preferred method. But how do
you
> do it?
> I've played around with batch files but I still can't seem to get it
right.
> Would someone please post the script.
> Thanks,
> Jim
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darryl Collins
> Sent: Sunday, May 01, 2011 10:30 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Store accdr File Locally or on a File Server?
>
>
>
____________________________________________________________________________
> ___________
>
> Note: This e-mail is subject to the disclaimer contained at the bottom of
> this message.
>
____________________________________________________________________________
> ___________
>
>
>
> This is the same approach I use. A script checks the version number of
the
> local FE vs the expected FE version no stored on the server. If they are
> different it automatically removes the local FE and downloads a new one
and
> then opens it. The user never even knows about the update process. All
> they do is double click on the database FE icon as usual and the rest
> happens seamlessly in the background.
>
> cheers
> Darryl.
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Monday, 2 May 2011 12:58 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Store accdr File Locally or on a File Server?
>
> I place them on the local PC simply because the time to get the pieces and
> parts is usually faster.
>
> I use a batch file which just copies the FE from a production directory on
> the server every time
> they open the fe, but there are utilities that check for the version and
> only copy if newer.
>
> John W. Colby
> www.ColbyConsulting.com
>
> On 5/1/2011 10:26 PM, Brad Marks wrote:
>> All,
>>
>> Background - Small firm, approximately 25 PCs.
>>
>> Currently no change control software, but we could put together something
> to do this.
>>
>> We have an Access 2007 application that has a Front End that is about 20
> MB.
>>
>> We have set up a folder for each user on the file server so that each
user
> can have their own copy of the Front End.
>>
>> We are debating whether we should store the Front End in each of the
> Users' Folders on the File server or store the Front End on the local PC's
> hard drive.
>>
>> Storing the Front End on the file server simplifies our procedures to
> release new versions, but it appears to takes several seconds to initiate
> the application when it is stored on the file server.
>>
>> Storing the Front End on the local PC's hard drive would reduce the
> application initiation time, but this approach would result in more
> complicated procedures when new versions of the application Front End are
> released.
>>
>> Is there any "Rule of Thumb" to consider in this decision (such as "any
> accdr over X MB should be stored locally").
>>
>> Are there other issues that we need to keep in mind?
>>
>> Thanks,
>> Brad
>>
>>
>>
>>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com