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

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.

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

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



wrote in message
news:1193187741.649516.128920@k35g2000prh.googlegroups.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.
>

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

"Neil" wrote:

>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/

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

Andy_Khosravi@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/

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

"Neil" wrote:

>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/

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

Andy_Khosravi@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/

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

"Tony Toews [MVP]" 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.

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/

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

"Tony Toews [MVP]" wrote:

>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/

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

wrote in message
news:1193187741.649516.128920@k35g2000prh.googlegroups.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

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

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.

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

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

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

Tony Toews [MVP] wrote:

> "Tony Toews [MVP]" 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.
>
>
> 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.

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

Thanks, a lot of responses here, I hadn't expected to get Tony himself
to respond. I was up late last night frantically trying to come up
with a solution to this problem. I just got into work about an hour
ago and have been basically running my own call center trying to get
this stuff ironed out.

Last night I went with Idea 2 as I hadn't had an opportunity to read
through these responses yet. My solution works, but it is not pretty.
I wasn't aware of the of CurrentProject.path property. What I did
(working with the knowledge I have) was attempt to copy the .ldb file
in the master FE folder, then read the error message that resulted. If
the .ldb file didn't exist then I resumed on as normal, otherwise if
the error was 70 it meant the .ldb file existed and that the
application had been opened incorrectly - the user was then kicked
with docmd.quit. I like the currentproject.path method a lot better
=).

When I say I'm not good at writing functions, I mean I'm not really
good at writing things like API calls or any other type of code that
references objects or programs outside of Access. Other then that, I
feel I'm *fairly* competent working with VBA if I don't say so myself
=).

I was aware that there were methods to grab the desktop path via a
Windows API call, I was just hoping there was an easier way. I noticed
in Tony's program that he used something like %APPDATA% as a path to
insure the files were always saved to the proper location, I was
hoping there was something like %Desktop% that could be entered as a
path name to always default something to the current users desktop.
Right now I'm inferring the path by using a function to pull their
employee id, then patching it together to determine the desktop path
("C:\Documents and Settings\" & userid & " \Desktop"). Works 90% of
the time, but apparently some of the users paths do not follow that
format. I've already manually sent the shortcut to them, so it's a
rather moot point now =(

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.

Again, thanks for all the feedback and ideas you guys have brought
forward. I really do appreciate it!

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

Andy_Khosravi@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/

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

Andy_Khosravi@bcbsmn.com wrote:

>When I say I'm not good at writing functions, I mean I'm not really
>good at writing things like API calls or any other type of code that
>references objects or programs outside of Access. Other then that, I
>feel I'm *fairly* competent working with VBA if I don't say so myself
>=).

Then API calls won't be a problem at all for you. They're quite easy actually. Do
ensure you save the code module before running the code though. If it barfs it'll
shut down Access and you'll lose your changes.

>I was aware that there were methods to grab the desktop path via a
>Windows API call, I was just hoping there was an easier way. I noticed
>in Tony's program that he used something like %APPDATA% as a path to
>insure the files were always saved to the proper location,

Yes, but what I really do when I encounter a % variable is the call the appropriate
API call and substitute in that string

>I was
>hoping there was something like %Desktop% that could be entered as a
>path name to always default something to the current users desktop.

No, see above.

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/

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

Salad wrote:

>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.

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/

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

On Oct 24, 11:58 am, "Tony Toews [MVP]"
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.

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

Andy_Khosravi@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.

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/

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

Tony Toews [MVP] wrote:

> Salad wrote:
>
>
>>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.
>
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
>

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

"Tony Toews [MVP]" wrote in
news:jmith3p0l28sg9156eug8e2vglvjeu2n4v@4ax.com:

> "Tony Toews [MVP]" wrote:

>>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/

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

lyle wrote in
news:1193227971.988218.134230@t8g2000prg.googlegroups.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/

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

On Oct 24, 3:53 pm, "David W. Fenton"
wrote:
> lyle wrote innews:1193227971.988218.134230@t8g2000prg.googlegroups.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.

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

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 =)

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

Salad wrote:

>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.

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/

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

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!

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

Andy_Khosravi@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/

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

Tony Toews [MVP] wrote:
> Andy_Khosravi@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.

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

Andy_Khosravi@bcbsmn.com wrote in
news:1193263046.030357.74620@i38g2000prf.googlegroups.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/