Seemingly unfixable problem with Access application 1

[psemianonymous]

This is something of a crosspost since I tried the newsgroups (comp.databases.ms-access) first. I've had no dynamite answers/solutions to my problem.

Here is the link:

http://groups.google.com/groups?dq=...UTF-8&oe=UTF-8&group=comp.databases.ms-access

You can check the same exact thread in slightly better format here:

http://dbforums.com/t842241.html

I have *really* spent some time trying to get this working properly, to no avail.


Any help is appreciated.

--Pete

 

[JeffHicks]

From a Citrix/Terminal Server perspective, my solution would mirror one that you have already received. Since I have no knowledge of Access programming, my solution would be to have a seperate frontend for each user. I have implemented this with minimal maintenance as follows:

Create a directory structure on the Citrix server(s) such that there was a main folder which contains a folder called master and will contain each of the user's folders. Copy the front end to the master copy. Use NTFS permissions to limit users' ability to do more than read that folder and it's contents. Create a batch file that creates a folder for the user (if it does not already exist); copies the front end from the Master folder into the user folder if (a) it doesn't exist or (b) it's is older than the copy in the Master folder (xcopy /d); and runs the Access front end. Publish the batch file as the application in Citrix.

Any time updates needed to be done, the application team would either give me the updated version and I would copy it each of the master folders (this was scripted of course), or they would copy it themselves (via the same script). I had a monthly scheduled job to purge user folders with dates that were older than a pre-defined age that depended on their update rate of the front end.

This solution is not the perfect one, but I have no Access knowledge to speak of and they were unable to fix their problem. Perhaps this is a good workaround for you too.

 

[vecjjk]

Pete,
I pretty much had this same issue with a Paradox application. You might check out Microsoft articles Q299603 and Q272582. We ended up changing the OpLocksDisabled value in the registry under the key HKEY_LOCAL_MACHINE\System\CCS\Services\Mrxsmb\Parameters to "0x1" as Q299603 suggests, and also downloaded the patch Q272582_W2K_SP3_X86_EN.exe as Q272582 suggests. This combination fixed our problem. However, these changes were for Win2000, so it may be different for NT4. Hopefully, this gives you another path to try.

Jeff

 

[psemianonymous]

Thanks for answers #1 and 2. I have done #1 already, and the situation has improved, but is by no means perfect. My last post in the thread details the crashing/burning taking place earlier today, using separate front-ends--the problem still occurs, though much less frequently now.

#2: Thanks. Q299603 - I thought that we had opportunistic locking disabled, but according to regedit on the terminal server, it's enabled. I'll look into this more. Thanks for the specific registry key (though I had to look into ...\Services\LanManWorkstation\Parameters instead ... either way, oplocks are on). Ironically enough, I recognized Q272582 by its number - it says that Win2k SP3 solves some problems. We're running NT4SP6, so I suppose we're up to date (as there will be no more service packs for that OS). Oh well.


Thanks for both your answers -- I will definitely look into this whole "OpLocks" thing next.