Access not finding linked tables

[Internet Arrow Limited]

Hi,

I have a requirement to write an access application that must run
under access97 and access2K. Some users will use Acess2K to access
data that will also be accessed by Access97 users. The source data
must therefore remain in Access97 format

The user community has a mixture of access97 on WinNT; access2K on
winNt and access2K on win2K.

I have written the application such that the databases are Access97.
The application is in a seperate database. The application fetches
data via linked tables.

When the application is installed on an Access2K PC, I upgrade the
application database to Access2K, but leave the linked tables as
Access97.

However, when running on WindowsNT, access fails to see the linked
tables.
The application database (that contains all the code) is called
"carallow", the data is stored in a database called "carallowtables".
Both are .mde files.

Tthese files are in seperate directories (eg, the carallowtables is
saved on a network drive accessible by all; the application is saved
on the user's harddisk). As an example, the data can be stored on
G:\tables with the application on c:\carallow. The directory
locations are stored as attributes of the database in
Properties("AppsLocation") and Properties("DBLocation")

I use the linked tbale manager to specify the location of the tables
(g:\tables\carallowtables.mde) and can see the data fine in native
access.

However, when I open carallow.mde and run the code from within the
application as follows

===========
Dim wrkJet As Workspace
Dim dbsCarallow As Database
Dim rstTemp As Recordset

Set wrkJet = CreateWorkspace("", "admin", "", dbUseJet)
Set dbsCarallow =
wrkJet.OpenDatabase(CurrentDb.Properties("AppsLoca tion") &
"carallow.mde")
Set rstTemp = dbsCarallow.OpenRecordset("SELECT * FROM batches
WHERE isnull(fileDate)", dbOpenDynaset)

===============

Access gives the error message "can not find table
c:\carallow\carallowtables.mde". In otherwords, it doesn't seem to
recognise that they are linked tables stored under g:\tables.

This only happens when the apps database and data database are in
seperate directories. It works fine when they are in the same
directory.

Am I doing something wrong or is this a bug that I need a fix for.

Any help would be gratefully appreciated,

Thanks,
Paul

[Peter Russell]

When you create an mde you effectively 'hard-code' the path to the object
libraries. This means you can't run an mde on a different folder config
to the one it is created on. I can't tell from what you have written
whether this is relevant to you or not. But I assume you can.

My other comment is that there is no point in converting the back-end to
an mde. It does nothing.

Regards

Peter Russell

Internet Arrow Limited previously wrote:

Hi,

I have a requirement to write an access application that must run
under access97 and access2K. Some users will use Acess2K to access
data that will also be accessed by Access97 users. The source data
must therefore remain in Access97 format

The user community has a mixture of access97 on WinNT; access2K on
winNt and access2K on win2K.

I have written the application such that the databases are Access97.
The application is in a seperate database. The application fetches
data via linked tables.

When the application is installed on an Access2K PC, I upgrade the
application database to Access2K, but leave the linked tables as
Access97.

However, when running on WindowsNT, access fails to see the linked
tables.
The application database (that contains all the code) is called
"carallow", the data is stored in a database called "carallowtables".
Both are .mde files.

[Dale Green]

"Peter Russell" <pr******@russellscott.co.uk> wrote in message
news:me**********************@russellscott.btinter net.com...

My other comment is that there is no point in converting the back-end to
an mde. It does nothing.

Oh... it does something and that something isn't good. You can't perform
certain run-time changes that one could in a MDB. For example, a MDE's
report that is dynamically altered (add a field, etc.) at runtime will throw
an error.

D.