Problems using a single Front End

  • Thread starter Thread starter BillA
  • Start date Start date
B

BillA

I am having problems with my database not responding to calls for it to open.
I believe my problem is coming from my security settings and the
Record-Locking .ldb files created when a user opens the database.

I have a read-only application with a Front End (FE) and Back End (BE)
sitting in the same shared network folder. We are running XP and using
Access 2003.

The network folder user permissions are Read & execute; List folders; Read &
Write. The FE and BE file permissions are inherited.

Same FE for everyone
Understanding it goes against my understanding and universal thought of how
a FE should be used – I’ve been told I am not able to place copies of my
application on our organizations desktops. I was given only one option; use
a shortcut from desktops that will open the database sitting on a shared
network folder. So we’ve placed a desktop shortcut on everyone’s desktop and
my fears are coming true; unresponsive shortcut – meaning the database is
locked up. At times there are more than a single user accessing the database
– but most of the time – not so much.

A little more about the application
Our application is strictly read only. Users access the FE an navigate
through a couple of informational pages to a search page. From there they
can search for a specific record, click on the record opening a Form
containing information about a record and may have a couple of hyperlinks to
web resources. In addition the user may choose to print this Form or a
report consisting of numerous records. The FE is a completely locked down
and highly secured .mde file - No data is input, no scrolling, no nothing.
This is just a read-only database.

I’m trying to find a way of getting rid of the Record-Locking .ldb file as I
don’t believe it is necessary in my read-only situation. I would appreciate
any suggestions as to how I can improve user interactivity while using a
single FE on the network.

Thank you,
Bill
 
Don't know how many users you have, is there any possibility of putting one
copy for each user (of the frontend) on the server?


Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia
 
Hello Jeanette,

Placing additional copies on the server wouldn't be feasible - we've only
rolled it out to a possible 500 user of a total of more than 2500 with
locations disbursed around our state. Reason to slow roll this application
to our workforce was to keep the interest factor down and keep any possible
access problems minimized. Eventually this application is meant to be a
organization tool that will be used infrequently by a minority group of users
- but will be available to all.

Thank you for your interest.
Bill
 
BillA said:
Same FE for everyone
Understanding it goes against my understanding and universal thought of
how
a FE should be used – I’ve been told I am not able to place copies of my
application on our organizations desktops.
Click to expand...

Depending on your organisation's IT policy, you might be able to deploy your
FE to the users' Temp folder in their profile. It's a method I use all the
time and it works by copying the FE file to the user's Temp folder on
demand, so only the users that want it get it.

The user's shortcut points to a batch file, an example of which follows
(A2003), hope it helps.

Keith.
www.keithwilby.co.uk

ECHO OFF

DEL "%temp%\FEFolder\*.*" /Q
RD "%temp%\FEFolder"
MKDIR "%temp%\FEFolder"

DEL "%userprofile%\desktop\MyShortcut.lnk"
XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"

XCOPY "X:\MyPath\MyFE.mde" "%temp%\FEFolder" /I
START "MyApp" /MAX "C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE"
"%temp%\FEFolder\MyFE.mde" /wrkgrp "X:\MyPath\MyWIF.mdw"
 
Keith,

BRILLIANT!
I must say I would not have thought of this tactic. Now to sell it to our
dogmatic IT department.

One question; if I want the user to open the application from a shortcut
placed on their desktop, would I need to delete and reinsert a shortcut;

DEL "%userprofile%\desktop\MyShortcut.lnk"
XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"

Maybe you could tell me the intent of this section of this script?

Your suggestion has given me so many ideas.

I’ll write back and let you know how ‘IT’ goes.

Thank you!
Bill
 
BillA said:
Keith,

BRILLIANT!
I must say I would not have thought of this tactic. Now to sell it to our
dogmatic IT department.

One question; if I want the user to open the application from a shortcut
placed on their desktop, would I need to delete and reinsert a shortcut;

DEL "%userprofile%\desktop\MyShortcut.lnk"
XCOPY "X:\MyPath\MyShortcut.lnk" "%userprofile%\desktop"

Maybe you could tell me the intent of this section of this script?

Your suggestion has given me so many ideas.

I’ll write back and let you know how ‘IT’ goes.

Thank you!
Bill
Click to expand...

Hi Bill. It might be that your users' Temp folders are wide open as are
mine, so you might not need IT's intervention at all. Just see if you can
save a large file to your own and see if it counts towards your profile size
(mine doesn't).

The purpose of the code is to wipe out pre-existing copies of the FE folder
and the desktop shortcut (if they exist) and copy across replacements. That
way your users always get the latest copies on demand. If they don't exist
then the "delete" parts will fail silently.

The lines of code you've singled out delete the desktop shortcut and copy
across its replacement.

You can roll out the shortcut to your users by e-mailing them a hyperlink to
the batch file. Of course, the public folder you use should be readable
(and read-only) to all of your users

Regards,
Keith.
www.keithwilby.co.uk
 
Hi Keith,

Success running the .bat file, but, there's always a 'but.'

The command prompt window doesn't disappear. And that is due, I believe,
due to the fact that I am trying to use UNC's to path to the proper folders.
I can't get around not using UNC's because everyones mapped directories will
be different. I get this message:
[my folder UNC]
"CMD.EXE was started with the above path as the current directory. UNC
Paths are not supported. Defaulting to Windows directory."

Is there a way of using the UNC to path to the folders

Here is the script I used:

ECHO OFF

DEL "%temp%\DSC_Folder\*.*" /Q
RD "%temp%\DSC_Folder"
MD "%temp%\DSC_Folder"

DEL "%userprofile%\desktop\Data Set Catalog1.lnk"
XCOPY "\\146.243.80.211\shared\Data_Access\Dataset_Catalog\DPH_USER\Data Set
Catalog1.lnk" "%userprofile%\desktop"

XCOPY
"\\146.243.80.211\shared\Data_Access\Dataset_Catalog\DPH_USER\DSC_fe.mde"
"%temp%\DSC_Folder" /I
START "DSC_FE" /MAX "C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE"
"%temp%\DSC_Folder\DSC_FE.mde"

Thank you for your time & assistance.
Bill
 
BillA said:
Hi Keith,

Success running the .bat file, but, there's always a 'but.'

The command prompt window doesn't disappear. And that is due, I believe,
due to the fact that I am trying to use UNC's to path to the proper
folders.
I can't get around not using UNC's because everyones mapped directories
will
be different. I get this message:
[my folder UNC]
"CMD.EXE was started with the above path as the current directory. UNC
Paths are not supported. Defaulting to Windows directory."

Is there a way of using the UNC to path to the folders
Click to expand...

UNCs work fine for me. Have you tried paths without spaces? Not sure what
else to suggest ...
 
BillA said:
Same FE for everyone
Understanding it goes against my understanding and universal thought of how
a FE should be used – I’ve been told I am not able to place copies of my
application on our organizations desktops. I was given only one option; use
a shortcut from desktops that will open the database sitting on a shared
network folder.
Click to expand...

How about the users local apps folder then? That's standard practice
to put these kinds of files in that folder. Just the shortcut would
go on the desktop, Quick Launch, or Start >> All Programs.

I see you're already looking at a batch file solution suggested by
Keith to the temp folder. Note that this type of solution will copy
down the new FE every time the user opens the FE. Which can load to
increased startup times and network load. Although not that
significant for a relatively small app such as yours?

As an alternative I'd suggest the Auto FE updater as in my sig below.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
Back
Top