No data in Backend

J

John G

Hi,
I have some clients running Windows Vista and some clients running Windows
XP. My database is developed using MS Access 2003 and is split. Both the FE
and BE reside in the same folder on the same computer. All clients are using
MS Access 2003 runtime. When my database program is opened the tables are
automatically relinked. After the client inputs data he tries to backup the
data (backend) by clicking on a menu item that points to the code to backup
the backend. He gets an error 3024..(can not locate the file.) Upon examining
the data file we discovered that it is empty but the data that he entered is
still showing in the forms. How can this be? This problem only occurs on
machines running Vista. It does not happen on Windows XP machines. When he
closes the database (frontend) and reopens it the data is still showing in
the forms, but the backend data file is empty.
I don't understand how there can be data showing in the forms but none in
the actual data file.
What is Vista doing with the data and why can it not locate the data file?
Anyone have any ideas?
 
D

dymondjack

I don't know anything about the details related to your particular problems,
but there's a few things I could point out as far as the setup to reduce the
chance of db corruption (which, as far as I can think of, is the only way you
might ever come up with a situation like this).
Both the FE and BE reside in the same folder on the same computer.

The FE should always be located on each user's own computer. Never share a
front end, it is a recipie for disaster. The chances of db corruption are
high when having more than one person use a front end. Many people will opt
to keep a master copy of the FE in the server location, but you should always
put a copy of FE on the local machine that the user runs.

After the client inputs data he tries to backup the
data (backend) by clicking on a menu item that points to the code to backup
the backend.

A backup of the BE should only be done when no users are logged in via the
front end (when there is no .ldb file for the BE). Otherwise, a connection
is open to the backend and trying to copy the file is a good way to corrupt a
database. There must be no active connections to the BE before trying to
back it up.


While these suggestions don't directly answer your specific issues, they may
be a big player in the fact that you are having troubles with the db.
Unfortunately, it does sound like a corruption issue, and even more
unfortunately, I wouldn't have the slightest idea about how to fix it. If
this is the case, you might end up starting from scratch as far as entering
data.


hth

--
Jack Leach
www.tristatemachine.com

- "Success is the ability to go from one failure to another with no loss of
enthusiasm." - Sir Winston Churchill
 
J

Jim Burke in Novi

It's possible that the drives are mapped differently on different computers.
If you have the name of the DB hard-coded for backup purposes, this won't
work if different users have drives mapped differently. i.e. if the DB is on
a server'c C drive, it's possible that for some users that drive is actually
mapped as something other than C. That's the only thing I can think of.

As for relinking, you should only re-link tables when you install a new
version of the FE and there are new tables that have been added. Otherwise
there is no need to re-link. In my experience re-linking causes the FE to
grow in size and over time if the FE keeps growing this can cause peformance
problems.
 
D

Dale Fye

I strongly endorse Jack's comments about:
1. FE on users PC's
2. Don't try to backup if someone is connected to the backend. What code
are you using for the backend backup? Like Jack said, first step is to see
whether the BE.mdb has an ldb file associated with it. If it does, don't try
to back it up. Since you indcate that your FE relinks the BE tables on
startup, you might want to go so far as to drop the tables from the FE prior
to attempting the backup.

Another thing you might want to consider is adding the ability to force
other users off, so you can execute the backup. I generally have a table
(db_Parameters) which contains a field (InMaintenance - Y/N) which is
defaulted to False. When I set check this box on my Admin form, it causes a
series of events to occur.

In the startup form of my applications, I include a Timer event that checks
every minute or so to see what the status of [InMaintenance] is (I also do
this in the startup forms open event). If [InMaintenance] = True then I
don't allow the user to open the application. If the application is already
open, it displays a warning message and starts a countdown timer which pops
up every two minutes (for 10-15 minutes). When the countdown timer reaches
zero, the application methodically closes all of the forms (in reverse to the
order they were opened), undoing the changes to the current record.

--
HTH
Dale

email address is invalid
Please reply to newsgroup only.
 
J

John G

dymondjack,
Thanks for the reply. I guess I wasn't clear about the databases.
First the databases that I'm referring to is NOT shared with anyone. These
databases are all independent of each other. In other words one client has
nothing to do with the other. The reason I split the database is so I can
send updated frontends without affecting the clients data. So as far as
backingup the backend there are never any other users logged on because it is
not possible. Each client has their own computer and their data is totaling
independent of anyone else.
As I stated in my orginal question this problem of no data in the data file
and not being able to locate the data file, ONLY occurs on Window Vista
machines.
Thanks dymondjack for your input but the situation you describe does not
apply to my problem.

John G
 
J

John G

Jim,
Thanks for your reply. I guess I wasn't clear about the databases.
These databases are all independent of each other. In other words one client
has nothing to do with the other. The database is installed in the same
folder on all computers and the name of the data file is NOT hard coded for
backup purposes. Each client has their own computer and their data is
totaling independent of anyone elses.
As I stated in my orginal question this problem of no data in the data file
and not being able to locate the data file, ONLY occurs on Window Vista
machines.
Thanks for your input Jim, but the situation you describe does not apply to
my problem.

John G
 
J

John G

Thanks for your reply Dale. My comments are inline.

Dale Fye said:
I strongly endorse Jack's comments about:
1. FE on users PC's

Users are NOT on any kind of a network. Each user is completely independent
of any other user. One has nothing to do with the other.
2. Don't try to backup if someone is connected to the backend.

Does not apply to my situation.

What code
are you using for the backend backup?

Here is the code:

Function CompactBackendData()
On Error GoTo CompactData_ERR

Dim LinkPathFile As String
Dim LinkPath As String
Dim LinkFile As String
Dim FileWithoutExtention As String
Dim strFolder As String
Dim strDateFileName As String
Dim strBackupName As String
Dim strDatabaseName As String

'uses the findsource, getpath, and getfile functions
'to determine the path and filename of the linked database
LinkPathFile = Mid(FindSource(), 11)
LinkPath = GetPath(LinkPathFile)
LinkFile = GetFile(LinkPathFile)
FileWithoutExtention = Left(LinkFile, InStr(LinkFile, ".") - 1)
'Compact the Back-End database to a temp file.
DBEngine.CompactDatabase LinkPath & LinkFile, LinkPath &
FileWithoutExtention & "Temp.mdb"

'Delete the previous backup file if it exists.
If Dir(LinkPath & FileWithoutExtention & ".bak") <> "" Then
Kill LinkPath & FileWithoutExtention & ".bak"
End If

'Rename the current database as backup and rename the temp file to
'the original file name.
Name LinkPath & LinkFile As LinkPath & FileWithoutExtention & ".bak"
Name LinkPath & FileWithoutExtention & "Temp.mdb" As LinkPath & LinkFile
'-- Make a datestamp filename like _yyyy-mm-dd.bak from the system date
'-- and add it to the path of the backup folder.

strFolder = GetOpenFile()
strDateFileName = MakeFileName()
strBackupName = strFolder & strDateFileName & ".bak"

strDatabaseName = GetPath(LinkPathFile) & FileWithoutExtention 'Get the
name of the Data file.
DBEngine.CompactDatabase strDatabaseName, strBackupName 'Compact old
Data file and make backup to new location with new name.

'If user clicks Cancel on dialog box do not make backup file.
If Dir(strBackupName) = "" Or Dir(strBackupName) = MakeFileName & ".bak"
Then
'user pressed cancel
Kill strBackupName
Err.Raise cERR_USERCANCEL


Else
'If user enters a name for backup file then inform them that backup was
successful.
myMsgBox "Your DATA file has been successfully backed up to..." & vbCrLf
& vbCrLf & strBackupName, vbOKOnly + vbInformation, "Backup Successful!"

End If


CompactData_End:

Exit Function

CompactData_ERR:

If Err.Number = 3024 Then 'Error 3024 is triggered when the DATA file
can not be found.
MsgBox "Could not locate the DATA file for backup."

End If
End If

If Dir(strBackupName) = "" Or Dir(strBackupName) = MakeFileName & ".bak"
Then
Select Case Err

Case cERR_USERCANCEL:
If myMsgBox("Backup of DATA file was unsuccessful!" & vbCrLf &
vbCrLf & "No location or file name was specified for your Backup file!" &
vbCrLf & vbCrLf & "Safeguard your data by backing it up to some type of
portable media such as: a USB flash drive (JumpDrive, SmartDrive or
TravelDrive), External Backup Hard Drive, CD-R, CD-RW or DVD+/-RW!", _
vbCritical + vbRetryCancel + vbMsgBoxHelpButton, "Backup
Unsuccessful", , 105) = vbRetry Then
CompactBackendData
End If
Resume CompactData_End

Case Else:
MsgBox Err.Description & vbCrLf & vbCrLf & "Compact and Backup of
DATA file was unsuccessful!" & vbCrLf & vbCrLf & "Close all open forms and
try again." & vbCrLf & vbCrLf & "You may have to close and reopen the
database before attempting BACKUP again."
Resume CompactData_End
End Select

End If

End Function

'=====End Code============

This code works on Windows XP PCs but does NOT work on Vista.


Like Jack said, first step is to see
whether the BE.mdb has an ldb file associated with it. If it does, don't try
to back it up. Since you indcate that your FE relinks the BE tables on
startup, you might want to go so far as to drop the tables from the FE prior
to attempting the backup.


Another thing you might want to consider is adding the ability to force
other users off, so you can execute the backup.

Does not apply to my situation.

I generally have a table
(db_Parameters) which contains a field (InMaintenance - Y/N) which is
defaulted to False. When I set check this box on my Admin form, it causes a
series of events to occur.

In the startup form of my applications, I include a Timer event that checks
every minute or so to see what the status of [InMaintenance] is (I also do
this in the startup forms open event). If [InMaintenance] = True then I
don't allow the user to open the application. If the application is already
open, it displays a warning message and starts a countdown timer which pops
up every two minutes (for 10-15 minutes). When the countdown timer reaches
zero, the application methodically closes all of the forms (in reverse to the
order they were opened), undoing the changes to the current record.


As stated before this problem only occurs on machines running Vista. It does
not happen on Windows XP machines. The backup works on Windows XP.

Any ideas Dale?
 
J

John G

Jack, Jim and Dale,

I figured out what is going on with the Vista machines. You see, by default
I have my program installed in C:\Program Files\myappfolder. The data file
(backend) resides in a subfolder of "myappfolder". Vista does not allow
writing to anything in the Program Files folder so it sends it to a
"virtualized folder" located at
C:\Users\username\AppData\Local\VirtualStore\Program Files\myappfolder. This
happens if the user opens the program without administrative or elevated
privileges. Although the data file is in C:\Program Files\myappfolder\appdata
it will not show any records because the actual records reside in the
"virtualized folder". Now I just have to figure out where I should be
installing the FE and BE so Vista will allow writing to it.

Again thanks to Jack, Jim and Dale for taking the time to reply to my
orginal question.

John G




Dale Fye said:
I strongly endorse Jack's comments about:
1. FE on users PC's
2. Don't try to backup if someone is connected to the backend. What code
are you using for the backend backup? Like Jack said, first step is to see
whether the BE.mdb has an ldb file associated with it. If it does, don't try
to back it up. Since you indcate that your FE relinks the BE tables on
startup, you might want to go so far as to drop the tables from the FE prior
to attempting the backup.

Another thing you might want to consider is adding the ability to force
other users off, so you can execute the backup. I generally have a table
(db_Parameters) which contains a field (InMaintenance - Y/N) which is
defaulted to False. When I set check this box on my Admin form, it causes a
series of events to occur.

In the startup form of my applications, I include a Timer event that checks
every minute or so to see what the status of [InMaintenance] is (I also do
this in the startup forms open event). If [InMaintenance] = True then I
don't allow the user to open the application. If the application is already
open, it displays a warning message and starts a countdown timer which pops
up every two minutes (for 10-15 minutes). When the countdown timer reaches
zero, the application methodically closes all of the forms (in reverse to the
order they were opened), undoing the changes to the current record.

--
HTH
Dale

email address is invalid
Please reply to newsgroup only.



John G said:
Hi,
I have some clients running Windows Vista and some clients running Windows
XP. My database is developed using MS Access 2003 and is split. Both the FE
and BE reside in the same folder on the same computer. All clients are using
MS Access 2003 runtime. When my database program is opened the tables are
automatically relinked. After the client inputs data he tries to backup the
data (backend) by clicking on a menu item that points to the code to backup
the backend. He gets an error 3024..(can not locate the file.) Upon examining
the data file we discovered that it is empty but the data that he entered is
still showing in the forms. How can this be? This problem only occurs on
machines running Vista. It does not happen on Windows XP machines. When he
closes the database (frontend) and reopens it the data is still showing in
the forms, but the backend data file is empty.
I don't understand how there can be data showing in the forms but none in
the actual data file.
What is Vista doing with the data and why can it not locate the data file?
Anyone have any ideas?
 
D

dymondjack

I had thought it might have something to do with that after finding out my
first suggestion wasn't applicable.

Unfortunately I'm not sure what folders are good for this. I have Vista at
my house, where I do a lot of my development, but all my work computers are
running XP so I never went too far with trying to figure it out.

I do know that I run into various file op errors if I put my dev version on
anything other than my secondary hard drive. I'm guess this is probably not
an option for you though.


Below is a quote from Tony Toews regarding placement of files for his autoFE
updating system, but I've never tested with Vista.

<quote>
MainApp=%appdata%\My Application
[]
While you can put an explicit directory such as "C:\My database" accessing
the C drive might be locked down by the administrator. Thus using the
Windows Application Directory is the best long term choice.
[]
Note that %ProgramFiles% is not recommended as users do not have update
rights to the Program Files directory.
</quote>
(link: http://www.granite.ab.ca/access/autofe.htm)


The 'Virtual folder' you refer to is a Junction from the XP location to the
new Vista location (AFIAK, Junctions were created to handle the differences
in default folder location changes between the two OS's). Everything
*should* be transferred to the juction destination folder, but vista is
tricky about this stuff.

Go to the cmd.exe and type SET to see a list of all the local variables for
that environment. You should see an APPDATA folder, and that may be the one
you want to go with. There's two ways to refer to that folder from access:

the Environ() function
ex. Environ("APPDATA")

or the more secure API
http://www.mvps.org/access/api/api0054.htm


Note that using Environ() can be problematic, especially in vista (what
isn't, in vista?)


Hopefully this helps out some. At least closer to home than my original
post...


--
Jack Leach
www.tristatemachine.com

- "Success is the ability to go from one failure to another with no loss of
enthusiasm." - Sir Winston Churchill
 
J

John G

Thanks for the information Jack.

I found this link helpful in determining which folders to install the data
file in. Thought you might be interested in reading what Doug Henning has to
say on the subject of installing programs on Vista machines.
http://doughennig.blogspot.com/2007/01/finding-paths-for-special-folders.html

John G



dymondjack said:
I had thought it might have something to do with that after finding out my
first suggestion wasn't applicable.

Unfortunately I'm not sure what folders are good for this. I have Vista at
my house, where I do a lot of my development, but all my work computers are
running XP so I never went too far with trying to figure it out.

I do know that I run into various file op errors if I put my dev version on
anything other than my secondary hard drive. I'm guess this is probably not
an option for you though.


Below is a quote from Tony Toews regarding placement of files for his autoFE
updating system, but I've never tested with Vista.

<quote>
MainApp=%appdata%\My Application
[]
While you can put an explicit directory such as "C:\My database" accessing
the C drive might be locked down by the administrator. Thus using the
Windows Application Directory is the best long term choice.
[]
Note that %ProgramFiles% is not recommended as users do not have update
rights to the Program Files directory.
</quote>
(link: http://www.granite.ab.ca/access/autofe.htm)


The 'Virtual folder' you refer to is a Junction from the XP location to the
new Vista location (AFIAK, Junctions were created to handle the differences
in default folder location changes between the two OS's). Everything
*should* be transferred to the juction destination folder, but vista is
tricky about this stuff.

Go to the cmd.exe and type SET to see a list of all the local variables for
that environment. You should see an APPDATA folder, and that may be the one
you want to go with. There's two ways to refer to that folder from access:

the Environ() function
ex. Environ("APPDATA")

or the more secure API
http://www.mvps.org/access/api/api0054.htm


Note that using Environ() can be problematic, especially in vista (what
isn't, in vista?)


Hopefully this helps out some. At least closer to home than my original
post...


--
Jack Leach
www.tristatemachine.com

- "Success is the ability to go from one failure to another with no loss of
enthusiasm." - Sir Winston Churchill


John G said:
Jack, Jim and Dale,

I figured out what is going on with the Vista machines. You see, by default
I have my program installed in C:\Program Files\myappfolder. The data file
(backend) resides in a subfolder of "myappfolder". Vista does not allow
writing to anything in the Program Files folder so it sends it to a
"virtualized folder" located at
C:\Users\username\AppData\Local\VirtualStore\Program Files\myappfolder. This
happens if the user opens the program without administrative or elevated
privileges. Although the data file is in C:\Program Files\myappfolder\appdata
it will not show any records because the actual records reside in the
"virtualized folder". Now I just have to figure out where I should be
installing the FE and BE so Vista will allow writing to it.

Again thanks to Jack, Jim and Dale for taking the time to reply to my
orginal question.

John G
 
D

dymondjack

Thanks for the link... it's good information to know.

Poor guy, came here for help and ends up giving me answers instead.

Glad you got it figured out in any case.

--
Jack Leach
www.tristatemachine.com

- "Success is the ability to go from one failure to another with no loss of
enthusiasm." - Sir Winston Churchill


John G said:
Thanks for the information Jack.

I found this link helpful in determining which folders to install the data
file in. Thought you might be interested in reading what Doug Henning has to
say on the subject of installing programs on Vista machines.
http://doughennig.blogspot.com/2007/01/finding-paths-for-special-folders.html

John G



dymondjack said:
I had thought it might have something to do with that after finding out my
first suggestion wasn't applicable.

Unfortunately I'm not sure what folders are good for this. I have Vista at
my house, where I do a lot of my development, but all my work computers are
running XP so I never went too far with trying to figure it out.

I do know that I run into various file op errors if I put my dev version on
anything other than my secondary hard drive. I'm guess this is probably not
an option for you though.


Below is a quote from Tony Toews regarding placement of files for his autoFE
updating system, but I've never tested with Vista.

<quote>
MainApp=%appdata%\My Application
[]
While you can put an explicit directory such as "C:\My database" accessing
the C drive might be locked down by the administrator. Thus using the
Windows Application Directory is the best long term choice.
[]
Note that %ProgramFiles% is not recommended as users do not have update
rights to the Program Files directory.
</quote>
(link: http://www.granite.ab.ca/access/autofe.htm)


The 'Virtual folder' you refer to is a Junction from the XP location to the
new Vista location (AFIAK, Junctions were created to handle the differences
in default folder location changes between the two OS's). Everything
*should* be transferred to the juction destination folder, but vista is
tricky about this stuff.

Go to the cmd.exe and type SET to see a list of all the local variables for
that environment. You should see an APPDATA folder, and that may be the one
you want to go with. There's two ways to refer to that folder from access:

the Environ() function
ex. Environ("APPDATA")

or the more secure API
http://www.mvps.org/access/api/api0054.htm


Note that using Environ() can be problematic, especially in vista (what
isn't, in vista?)


Hopefully this helps out some. At least closer to home than my original
post...


--
Jack Leach
www.tristatemachine.com

- "Success is the ability to go from one failure to another with no loss of
enthusiasm." - Sir Winston Churchill


John G said:
Jack, Jim and Dale,

I figured out what is going on with the Vista machines. You see, by default
I have my program installed in C:\Program Files\myappfolder. The data file
(backend) resides in a subfolder of "myappfolder". Vista does not allow
writing to anything in the Program Files folder so it sends it to a
"virtualized folder" located at
C:\Users\username\AppData\Local\VirtualStore\Program Files\myappfolder. This
happens if the user opens the program without administrative or elevated
privileges. Although the data file is in C:\Program Files\myappfolder\appdata
it will not show any records because the actual records reside in the
"virtualized folder". Now I just have to figure out where I should be
installing the FE and BE so Vista will allow writing to it.

Again thanks to Jack, Jim and Dale for taking the time to reply to my
orginal question.

John G
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top