By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,929 Members | 634 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,929 IT Pros & Developers. It's quick & easy.

Copy FE of DB when it is already open on the server

P: n/a
I just recently changed my database that I'm running from a monolithic
DB to a split FE/BE. The front end resides on the client machine and
the BE resides on a network drive. I'm experimenting with a utility
developed by Tony Toews to handle the distribution and subsequent
updates of the software. I'm having some trouble with the overall
upgrade process I've implemented, and I'm hoping one of you may have
an idea how to go about fixing it.

The application works great so long as the users follow the
instructions. They click a shortcut, which used to lead to the old
monolithic database, but has since been switched out with a simple
form that explains that the system has been upgraded. The form load
event dumps a shortcut to their desktop (a shortcut made by Tony's
utility) that they then click to get into the newly split (and
upgraded from A97 to A03) application.

The first problem I'm having is that I can't seem to get my upgrade db
to correctly dump the shortcut to the desktop 100% of the time. It
works 9/10 times, but it would appear that some users have a path to
their desktop which is non conforming to the standard. If it fails, it
pops them a message to contact me and I manually send them the
shortcut. I would like this to work 100% of the time, but to do that I
would need some sort of generic path that will always lead to the
current user's desktop rather than trying to infer it based on their
user id.

The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony's program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can't using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.

Correcting the problem by educating the users is extremely difficult
as there are just under 700 of them. They get so many e-mails and
other forms of updates that some people wouldn't end up getting the
memo, and it only takes one person to foul it up. What's made it worse
is that once it is locked up like this, the only way to open it at all
(and for them to get their work done) is to open it incorrectly by
opening up the master FE database. They found that out quick and have
been shooting e-mails all over the place letting people in on 'the
secret'.

To correct this issue, I need some way to insure that they absolutely
cannot use the master FE database. However, I can't just make it auto
close, because it still needs to be copied to the client machine. If I
modify it so that it won't open on the network, then it won't open on
their client machine either.

I've been thinking on it, and have come up with a few possible
solutions, but I wonder if any of you might have some better ideas or
comments.

Idea 1) Create a new network folder for the master FE file to exist in
by itself (as apposed to putting it in the same folder with the
backend). Give everybody in the company read only access and give
myself read/write access.

Cons: Would take up to 2 weeks to get all the paper work filled out
and the changes approved (yes, I know that is asinine.) Furthermore,
I'm not sure that it would work as people would still be able to open
it (albeit, only exclusively) and maybe even make some table updates
(?) as the BE is in a folder they would have read/write access to.

Idea 2) write a module that runs on startup to determine if there is
an ldb file in the master FE folder. If there is, attempt to delete
the .ldb file(in case it didn't auto remove itself when the last user
logged in) then close the program. The idea here is that if you log in
properly, you won't create an .ldb file in the master FE folder, but
if you did log in improperly then you will inevitably create an .ldb
file in that directory which then prompts the application to close.

Cons) I'm not really good at writing functions. I know how to copy a
file and how to delete one, but not how to simply check if one exists.
Maybe I can tinker with it and get it to work in a round about way.

Thanks in advance for any advice any of you may provide.

Oct 24 '07 #1
Share this Question
Share on Google+
25 Replies


P: n/a
First, regarding autoclose, you can easily accomplish that as follows. When
the FE is opened, check its path, using the currentproject.Path property. If
all users are to have it installed on the C drive, then just do something
like,

If Left(CurrentProject.Path,2)<"C:" then
msgbox "This application must be installed on the C drive. Application
will now quit.", vbcritical
application.quit
End If

There might be a more elegant solution than the above. But that would work.

Another approach would be to rename the extension to mydb.qde or something
like that. They wouldn't know what it was. Then, when you copy it to the C
drive, rename it to mydb.mdb. That would also work.

Neil

<An***********@bcbsmn.comwrote in message
news:11**********************@k35g2000prh.googlegr oups.com...
>I just recently changed my database that I'm running from a monolithic
DB to a split FE/BE. The front end resides on the client machine and
the BE resides on a network drive. I'm experimenting with a utility
developed by Tony Toews to handle the distribution and subsequent
updates of the software. I'm having some trouble with the overall
upgrade process I've implemented, and I'm hoping one of you may have
an idea how to go about fixing it.

The application works great so long as the users follow the
instructions. They click a shortcut, which used to lead to the old
monolithic database, but has since been switched out with a simple
form that explains that the system has been upgraded. The form load
event dumps a shortcut to their desktop (a shortcut made by Tony's
utility) that they then click to get into the newly split (and
upgraded from A97 to A03) application.

The first problem I'm having is that I can't seem to get my upgrade db
to correctly dump the shortcut to the desktop 100% of the time. It
works 9/10 times, but it would appear that some users have a path to
their desktop which is non conforming to the standard. If it fails, it
pops them a message to contact me and I manually send them the
shortcut. I would like this to work 100% of the time, but to do that I
would need some sort of generic path that will always lead to the
current user's desktop rather than trying to infer it based on their
user id.

The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony's program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can't using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.

Correcting the problem by educating the users is extremely difficult
as there are just under 700 of them. They get so many e-mails and
other forms of updates that some people wouldn't end up getting the
memo, and it only takes one person to foul it up. What's made it worse
is that once it is locked up like this, the only way to open it at all
(and for them to get their work done) is to open it incorrectly by
opening up the master FE database. They found that out quick and have
been shooting e-mails all over the place letting people in on 'the
secret'.

To correct this issue, I need some way to insure that they absolutely
cannot use the master FE database. However, I can't just make it auto
close, because it still needs to be copied to the client machine. If I
modify it so that it won't open on the network, then it won't open on
their client machine either.

I've been thinking on it, and have come up with a few possible
solutions, but I wonder if any of you might have some better ideas or
comments.

Idea 1) Create a new network folder for the master FE file to exist in
by itself (as apposed to putting it in the same folder with the
backend). Give everybody in the company read only access and give
myself read/write access.

Cons: Would take up to 2 weeks to get all the paper work filled out
and the changes approved (yes, I know that is asinine.) Furthermore,
I'm not sure that it would work as people would still be able to open
it (albeit, only exclusively) and maybe even make some table updates
(?) as the BE is in a folder they would have read/write access to.

Idea 2) write a module that runs on startup to determine if there is
an ldb file in the master FE folder. If there is, attempt to delete
the .ldb file(in case it didn't auto remove itself when the last user
logged in) then close the program. The idea here is that if you log in
properly, you won't create an .ldb file in the master FE folder, but
if you did log in improperly then you will inevitably create an .ldb
file in that directory which then prompts the application to close.

Cons) I'm not really good at writing functions. I know how to copy a
file and how to delete one, but not how to simply check if one exists.
Maybe I can tinker with it and get it to work in a round about way.

Thanks in advance for any advice any of you may provide.

Oct 24 '07 #2

P: n/a
"Neil" <no****@nospam.netwrote:
>There might be a more elegant solution than the above. But that would work.
Agreed. That was going to be my suggestions. Although that wouldn't necessarily
work in a Terminal Server environment where the FE is kept on a file server. However
there could be a work around there.
>Another approach would be to rename the extension to mydb.qde or something
like that. They wouldn't know what it was. Then, when you copy it to the C
drive, rename it to mydb.mdb. That would also work.
I dunno. His users are some sneaky SOBs.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #3

P: n/a
An***********@bcbsmn.com wrote:
>The first problem I'm having is that I can't seem to get my upgrade db
to correctly dump the shortcut to the desktop 100% of the time. It
works 9/10 times, but it would appear that some users have a path to
their desktop which is non conforming to the standard.
You really want to use the API call to get this information. Which is what I use.un
the Auto FE Updater. http://vbnet.mvps.org/code/shell/desktoplink.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #4

P: n/a
"Neil" <no****@nospam.netwrote:
>First, regarding autoclose, you can easily accomplish that as follows. When
the FE is opened, check its path, using the currentproject.Path property. If
all users are to have it installed on the C drive, then just do something
like,

If Left(CurrentProject.Path,2)<"C:" then
msgbox "This application must be installed on the C drive. Application
will now quit.", vbcritical
application.quit
End If

There might be a more elegant solution than the above. But that would work.
Actually I'd be real tempted to launch the Auto FE Updater with the appropriate INI
file specifed using the VBA Shell function.

IOW scr*w you you SOB user the app is going to do things the correct way despite your
best means of getting around it. Hehehehe. I like that approach.

Darn, I wrote my arm I patted myself on the back so hard.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #5

P: n/a
An***********@bcbsmn.com wrote:
>The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony's program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can't using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.
Furthermore, as soon as you open an MDB/MDE the date/time of the file changes. So
even users who are legitimately wanting to run your app a minute later get to attempt
to copy down the FE. Which of course fails. Arrrrgghhh. I can see a lot of
frustration on your part.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #6

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote:
>>The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony's program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can't using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.

Furthermore, as soon as you open an MDB/MDE the date/time of the file changes. So
even users who are legitimately wanting to run your app a minute later get to attempt
to copy down the FE. Which of course fails. Arrrrgghhh. I can see a lot of
frustration on your part.
Neil's suggestion might help solve this problem as the MDB file date/time might not
get changed until you actually open a form or query. Thus helping to avoid recopying
down the file using the AutoFEUpdater every time that changes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #7

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote:
>Actually I'd be real tempted to launch the Auto FE Updater with the appropriate INI
file specifed using the VBA Shell function.
Just to make that clear. If you look at the properties >Target of a shortcut
created by the Auto FE Updater you will see a line similar to

Q:\1_vb\StartMDB\StartMDB.exe /cmd /inifile:"Q:\1_vb\StartMDB\Drive Letter
example.ini"

Please your equivalent in the Shell function line.
>Darn, I wrote my arm I patted myself on the back so hard.
Hurt not wrote.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #8

P: n/a
<An***********@bcbsmn.comwrote in message
news:11**********************@k35g2000prh.googlegr oups.com...
>
The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony's program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application.
Have you considered implementing user-level security? Unless your users are
*very* Access savvy and have some lock picking tools then it will keep them
from doing this.
>
Correcting the problem by educating the users is extremely difficult
as there are just under 700 of them.
Getting users to use an app *your* way is nigh on impossible I'd say.
>
Idea 1) Create a new network folder for the master FE file to exist in
by itself (as apposed to putting it in the same folder with the
backend). Give everybody in the company read only access and give
myself read/write access.
This, coupled with ULS is what I use and it's been flawless for as long as I
can remember. Why do you need any paperwork to change file permissions? If
your IT provider has removed the security table from file properties, you
might still be able to control permissions from a DOS prompt using Access
Control Lists. Type "cacls" at a DOS prompt for more information.

Regards,
Keith.
www.keithwilby.com

Oct 24 '07 #9

P: n/a
On Oct 23, 9:02 pm, Andy_Khosr...@bcbsmn.com wrote:
Correcting the problem by educating the users is extremely difficult
as there are just under 700 of them.
I'm not really good at writing functions.
When I deliver an application I deliver it to the IT department. Its
members install it. I have no authority or permissions to install
anything, and would probably not get any more contracts if I tried.

Perhaps, your organization should consider giving you more help. IMO,
if "your" database is helping 700 users, and you're "not really good
at writing functions" some paid-for training sound like a good idea to
me. And surely it would be worthwhile to have someone, or multiple
someones to deal with those network and associated problems you
describe, that go beyond db development.

When I make an application available to a group of friends in a more-
or-less informal manner, I generally put it on the net as a self-
extracting zip file and send them the link. (There are free
utilities , eg IZArc, that create self-extracting zips; the utility is
not required for the extracting part.) I may change the extension
to"dat" to help with security, but I'm not sure that helps anymore.


Oct 24 '07 #10

P: n/a
Tony Toews [MVP] wrote:

Hi Tony. Since there's been mention of the FEUpdater in this thread, I
was wondering if you could help me out with a couple sits. I am testing
on a standalone PC, no network connection.

I created an ICO file. When I selected it, it would prompt me for the
ResourceID. It had never been used in any desktop shortcut. I hit
finish but it told me I needed to enter a resource id. I then went and
created a desktop id to open the app. Once I did that and selected the
..ico it accepted the .ico. Is that how it works?

I have an MDW. I have tried various methods but I keep getting errors.
At one point, I'm not sure what I did, I got a subscript out of range.
I can't duplicate that now, but here's a list of some of the ways I've
tried inside the ini file using the ValidateINI button. Do you have any
suggestions on what I need to correct?

Auto FE Updater Version: 1.73.0
Windows Version: Windows XP 5.1 build 2600 (Service Pack 2)

Error 1
'uses same MDW as FE. Uses MDW File, User, PW. My A97 is another folder.
Error 1017. The Access 97 ms-access was not found.
[Settings]
MainApp=%appdata%\PV\PVFE.mdb
Server=C:\FEFiles
StartMethod=AutoSelect
MDWFile=C:\PV\PVFE.MDW
MDWUser=Freg
MDWPassword=fred
MDWPasswordEncrypted=C03DDCAD
Error 2
'no ref to MDW, no MDW stuff.. Doesn't matter if using a regular user or
user with all rights
Error 1019. DAO Error 3033 called. Don't have necessary permissions
[Settings]
MainApp=%appdata%\PV\PVFE.mdb
Server=C:\FEFiles
StartMethod=AutoSelect
Error 3
'refs a different MDW from name of name of frontend.
Error 1022. MDW AcctName/Password weren't valid to determine version
[Settings]
MainApp=%appdata%\PV\PVFE.mdb
Server=C:\FEFiles
StartMethod=AutoSelect
MDWFile=C:\PV\Test.MDW
MDWUser=Freg
MDWPassword=fred
MDWPassword=C03DDCAD

Error 4
'specifies a command line. No MDW stuff
Error 1019. DAO Error 3033 called. Don't have necessary permissions
[Settings]
MainApp=%appdata%\PV\PVFE.mdb
Server=C:\FEFiles
StartMethod=AutoSelect
CommandLine="C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\FEFiles\PVFE.mdb" /wrkgrp C:\PV\PVFE.mdw

Error 5
'specifies a command line and MDW stuff
Error 1017. The Access 97 ms-access was not found.
[Settings]
MainApp=%appdata%\PV\PVFE.mdb
Server=C:\FEFiles
StartMethod=AutoSelect
CommandLine="C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\FEFiles\PVFE.mdb" /wrkgrp C:\PV\PVFE.mdw
MDWFile=C:\PV\PVFE.MDW
MDWUser=Freg
MDWPassword=fred
MDWPassword=C03DDCAD
Oct 24 '07 #11

P: n/a
Tony Toews [MVP] wrote:
"Tony Toews [MVP]" <tt****@telusplanet.netwrote:

>>>The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony's program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can't using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.

Furthermore, as soon as you open an MDB/MDE the date/time of the file changes. So
even users who are legitimately wanting to run your app a minute later get to attempt
to copy down the FE. Which of course fails. Arrrrgghhh. I can see a lot of
frustration on your part.


Neil's suggestion might help solve this problem as the MDB file date/time might not
get changed until you actually open a form or query. Thus helping to avoid recopying
down the file using the AutoFEUpdater every time that changes.

Tony
Hi Tony.

I just tried your FEUploader util. That's one sweet util.

I was having problems testing it on my stand-alone PC so I decided to
test it on the client's network. It worked like a champ. I was really
impressed.
Oct 24 '07 #12

P: n/a
An***********@bcbsmn.com wrote:
>Tony, your FE updater is working great once I got this problem fixed
except for one new problem. The executable file seems to periodically
'gut' itself. I don't know how else to explain it. It will be working
fine one moment, and then all of the sudden people will not be able to
get in. Upon investigation, I see that the executable file (normally
228 Kb) has lost its custom icon and is now only 500 bytes in size.
The file name hasn't changed or anything, it just appears that the
program has become seriously corrupted. I haven't any idea what is
causing the problem, but I've had to replace that executable file with
one from my desktop about 4 times today.
Whoa, now that's one I've never heard of. I suspect sabotage quite honestly. Can
you flag it as read only for now? Anyone knowledgable will know how to get around
that though.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #13

P: n/a
Salad <oi*@vinegar.comwrote:
>I just tried your FEUploader util. That's one sweet util.
>I was having problems testing it on my stand-alone PC so I decided to
test it on the client's network. It worked like a champ. I was really
impressed.
Thanks for your kind words. They make the effort worth while.

More enhancements coming soon. Which means in a month or two. <smile>

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #14

P: n/a
On Oct 24, 11:58 am, "Tony Toews [MVP]" <tto...@telusplanet.net>
wrote:
Andy_Khosr...@bcbsmn.com wrote:
Tony, your FE updater is working great once I got this problem fixed
except for one new problem. The executable file seems to periodically
'gut' itself. I don't know how else to explain it. It will be working
fine one moment, and then all of the sudden people will not be able to
get in. Upon investigation, I see that the executable file (normally
228 Kb) has lost its custom icon and is now only 500 bytes in size.
The file name hasn't changed or anything, it just appears that the
program has become seriously corrupted. I haven't any idea what is
causing the problem, but I've had to replace that executable file with
one from my desktop about 4 times today.

Whoa, now that's one I've never heard of. I suspect sabotage quite honestly. Can
you flag it as read only for now? Anyone knowledgable will know how to get around
that though.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
I am wondering if perhaps the company anti virus is corrupting it? Or
perhaps, some users don't have the required files to run the
executable, and the resulting error corrupts the file? I don't think
anybody would sabatoge it on purpose, but people are causing lots of
problems poking around in the folder this database resides in. Earlier
today, somebody deleted the (probably cut rather than copied) the
master shortcut that calls your program, and I see evidence of people
trying to make their own shortcuts not knowing what they are doing
(they are making shortcuts to the .ico icon files thinking that is the
shortcut). Most of these users are not technically savvy ( I had to
explain how to save an e-mail attachment to your desktop to more than
half of them....), but know just enough to cause trouble. I don't know
what they could possibly do to mess up that executable file.

I just flagged it as Read Only now, and I'll post back here if that
solves the problem.

Oct 24 '07 #15

P: n/a
An***********@bcbsmn.com wrote:
>I am wondering if perhaps the company anti virus is corrupting it?
Possibly but highy unlikely.
>Or
perhaps, some users don't have the required files to run the
executable, and the resulting error corrupts the file?
That shouldn't be happening. The VB6 runtime is installed by default on all Windows
XP computers. Also if they didn't have the VB6 runtime they'd get an appropriate
message.
>I don't think
anybody would sabatoge it on purpose, but people are causing lots of
problems poking around in the folder this database resides in. Earlier
today, somebody deleted the (probably cut rather than copied) the
master shortcut that calls your program, and I see evidence of people
trying to make their own shortcuts not knowing what they are doing
(they are making shortcuts to the .ico icon files thinking that is the
shortcut).
Create a shortcut for the users to click on in a folder down the tree a bit or in the
root of a share. So that's all they can see or are told about. Of course that
would've been great advice a few days ago. <smile>

But also change the files to read only to help stop a lot of this mucking about.
>I just flagged it as Read Only now, and I'll post back here if that
solves the problem.
Ok.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 24 '07 #16

P: n/a
Tony Toews [MVP] wrote:
Salad <oi*@vinegar.comwrote:

>>I just tried your FEUploader util. That's one sweet util.

>>I was having problems testing it on my stand-alone PC so I decided to
test it on the client's network. It worked like a champ. I was really
impressed.


Thanks for your kind words. They make the effort worth while.

More enhancements coming soon. Which means in a month or two. <smile>
In the movie Romancing the Stone the character Ira leaves Ralph (Danny
DaVito) on the wharf to handle the cops as he speeds away in a boat.
Ralph cries out "Ira, come back!" Ira replies "Sooooon!" And Ralph
responds "How sooooon???"

Looking forward to it. The biggest improvement I can see would be a
data entry form of actions that literally builds the ini. Convert
drives and provide the UNC paths where appropriate.

BTW, at your website there's the line "Now you choose some method of the
user executing it for the first time at the client workstations." Do
you have a preferred method for doing so? Would emails with an
attachment be the best?
Tony
Oct 24 '07 #17

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:jm********************************@4ax.com:
"Tony Toews [MVP]" <tt****@telusplanet.netwrote:
>>Darn, I wrote my arm I patted myself on the back so hard.

Hurt not wrote.
Well, depending on how your "wrote" it, that could hurt, too.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 24 '07 #18

P: n/a
lyle <ly************@gmail.comwrote in
news:11**********************@t8g2000prg.googlegro ups.com:
Perhaps, your organization should consider giving you more help.
IMO, if "your" database is helping 700 users, and you're "not
really good at writing functions" some paid-for training sound
like a good idea to me. And surely it would be worthwhile to have
someone, or multiple someones to deal with those network and
associated problems you describe, that go beyond db development.
Yes, I would say the problems he is having with people subverting
the new setup is a management problem, not a technical problem. Yes,
there are technical things he can do to make it harder, but the fact
that people are attempting to subvert the proper setup of the app
should be grounds for administrative discipline by the superiors of
the offenders. If they do it more than once (after having been told
not to do it again), they should be fired.

If there is no penalty for this kind of subversion of shared
applications, it's obviously not a well-managed organization.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 24 '07 #19

P: n/a
On Oct 24, 3:53 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
lyle <lyle.fairfi...@gmail.comwrote innews:11**********************@t8g2000prg.googleg roups.com:
Perhaps, your organization should consider giving you more help.
IMO, if "your" database is helping 700 users, and you're "not
really good at writing functions" some paid-for training sound
like a good idea to me. And surely it would be worthwhile to have
someone, or multiple someones to deal with those network and
associated problems you describe, that go beyond db development.

Yes, I would say the problems he is having with people subverting
the new setup is a management problem, not a technical problem. Yes,
there are technical things he can do to make it harder, but the fact
that people are attempting to subvert the proper setup of the app
should be grounds for administrative discipline by the superiors of
the offenders. If they do it more than once (after having been told
not to do it again), they should be fired.

If there is no penalty for this kind of subversion of shared
applications, it's obviously not a well-managed organization.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
The behavior is more than likely not intentional. Problems like this
are simply a function of how many people you have using the
application and how well educated they are. The probability of these
types of things happening grows to a near certainty once you reach a
certain user base; as that risk profile grows, the designer must
necessarily become increasingly responsible for such problems rather
than the end user. At least that's my personal design philosophy.

In this case it is very difficult to communicate to my end users; e-
mails get lost in the mass of other emails they get, the sheer number
of users makes it difficult to call them, and it is even more
impractical to pull them into a meeting to provide training. While
some of them work in this application all day, others only might use
it twice a month. The combination of these factors leaves them largely
ignorant of what effect changing things in that folder will have,
especially when it was something that they used to be able to do
without any problems.

Oct 24 '07 #20

P: n/a
Tony Wrote:

"Neil's suggestion might help solve this problem as the MDB file date/
time might not
get changed until you actually open a form or query. Thus helping to
avoid recopying
down the file using the AutoFEUpdater every time that changes."

I just got around to experimenting with this particular aspect now.
When I wrote my module I put it in the form load of the initial splash
screen, and it does not trigger off that the DB was modified, so
that's good. Apparently loading a form doesnt trigger that, or at
least triggering an unbound form doesn't.

I really wish I'd had a chance to read some of these suggestions
first. Changing the extension of the master FE copy would have been by
far the easiest way to do it *palm on forhead*

Tony, as far as changing your executable to read only goes...so far so
good. I will know for sure tomorrow morning as peak load times are
between 7-10 am. If I haven't said it before, I will say it again:
Thanks for the advice and double thanks for the utility =)

Oct 24 '07 #21

P: n/a
Salad <oi*@vinegar.comwrote:
>In the movie Romancing the Stone the character Ira leaves Ralph (Danny
DaVito) on the wharf to handle the cops as he speeds away in a boat.
Ralph cries out "Ira, come back!" Ira replies "Sooooon!" And Ralph
responds "How sooooon???"
<chuckle>
>Looking forward to it. The biggest improvement I can see would be a
data entry form of actions that literally builds the ini. Convert
drives and provide the UNC paths where appropriate.
Yes, that's very hihg on my list.
>BTW, at your website there's the line "Now you choose some method of the
user executing it for the first time at the client workstations." Do
you have a preferred method for doing so? Would emails with an
attachment be the best?
I should flesh that out a bit. I don't use Outlook so I'm not sure how the URLs work
there, etc, etc. Thanks for the reminder.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 25 '07 #22

P: n/a
Well, the program has been up for another day and my voicemail has
been blessedly silent. Not one single e-mail (about this issue anyway)
so far, and all appears to be well. Changing the executable to Read
Only appears to have corrected that issue.

Now all I have to do is figure out how to get the DB to run as fast as
it used to when it was in monolithic format, but that is another topic
for another day. Thanks again for all the helpful advice!

Oct 25 '07 #23

P: n/a
An***********@bcbsmn.com wrote:
>Well, the program has been up for another day and my voicemail has
been blessedly silent. Not one single e-mail (about this issue anyway)
so far, and all appears to be well. Changing the executable to Read
Only appears to have corrected that issue.
Fabulous! Quite the "learning experience".
>Now all I have to do is figure out how to get the DB to run as fast as
it used to when it was in monolithic format, but that is another topic
for another day. Thanks again for all the helpful advice!
Access Performance FAQ page at http://www.granite.ab.ca/access/performancefaq.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Oct 25 '07 #24

P: n/a
Tony Toews [MVP] wrote:
An***********@bcbsmn.com wrote:

>>Well, the program has been up for another day and my voicemail has
been blessedly silent. Not one single e-mail (about this issue anyway)
so far, and all appears to be well. Changing the executable to Read
Only appears to have corrected that issue.


Fabulous! Quite the "learning experience".

>>Now all I have to do is figure out how to get the DB to run as fast as
it used to when it was in monolithic format, but that is another topic
for another day. Thanks again for all the helpful advice!


Access Performance FAQ page at http://www.granite.ab.ca/access/performancefaq.htm

Tony
Added to the link by Tony...(these were in his links) I have found that
1) It is IMPERATIVE you use SHORT file names. No
MagicalAppBackEnd.MDB. Make it MGBE.MDB. Long filenames are an
absolute speed killers. 8.3 is the key.

2) Create a persistent link to some table.

3) Keep near the root. No
F:\Test\Testing\MoreTesting\MagicalBankEnd.MDB. Make it
F:\MGBE\MGBE.MDB

It wasn't until I did #1 that I found satisfactory speed. I couldn't
believe the difference shortening the filename would make.
Oct 25 '07 #25

P: n/a
An***********@bcbsmn.com wrote in
news:11*********************@i38g2000prf.googlegro ups.com:
In this case it is very difficult to communicate to my end users;
e- mails get lost in the mass of other emails they get, the sheer
number of users makes it difficult to call them, and it is even
more impractical to pull them into a meeting to provide training.
While some of them work in this application all day, others only
might use it twice a month. The combination of these factors
leaves them largely ignorant of what effect changing things in
that folder will have, especially when it was something that they
used to be able to do without any problems.
These are, again, management problems. You should not be the one
telling them these things -- their bosses should be.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Oct 25 '07 #26

This discussion thread is closed

Replies have been disabled for this discussion.