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

Access RT problem

P: n/a
Hello all,

In a split database environment, is it safe to still use the following?:

set db = CurrentDB

or must one be more explicit and indicate the path and name of the database
being initialized?

Also, how safe is it to have different operating systems accessing the
backend? Is one better off having all PCs using the same operating system?

thanks

Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Mon, 29 Sep 2003 06:33:37 GMT in comp.databases.ms-access, "Marc B"
<mb******@hotmail.com> wrote:
Hello all,

In a split database environment, is it safe to still use the following?:

set db = CurrentDB

or must one be more explicit and indicate the path and name of the database
being initialized?
Depends, for the most part CurrentDB is fine as your backend database
will be linked to the front end. You only need be explicit about
addressign the backend if you intend to use ISAM methods to access
your data (e.g. dbOpenTable, .Index, .Seek).
Also, how safe is it to have different operating systems accessing the
backend? Is one better off having all PCs using the same operating system?


You could ask if it is safe to use the same OS? <g>

I copied a front-end MDB to my laptop the other day, at the time I
copied it, the laptop was actually running it, it complained about an
unrecognizable database format, hardly surprising since it was being
changed at the bit level from underneath. Both machines had WinXP Pro.

--
A)bort, R)etry, I)nfluence with large hammer.
Nov 12 '05 #2

P: n/a
mb******@hotmail.com (Marc B) wrote in
<5n*****************@nwrdny01.gnilink.net>:
In a split database environment, is it safe to still use the
following?:

set db = CurrentDB

or must one be more explicit and indicate the path and name of the
database being initialized?
If you have linked tables, then CurrentDB() will work fine.

You can split a database and have no table links, so in that
context, operations on data in tables in the back end would require
the explicit name/path of the back end data file.
Also, how safe is it to have different operating systems accessing
the backend? Is one better off having all PCs using the same
operating system?


It doesn't matter so much what the clients are so much as what the
OS of the machine where the shared file resides. I would always put
the back end on the most advanced version of Windows available in a
peer-to-peer situation, and on the most advanced server OS in a
situation with a file server. The only exception for this is that
Win2K is for me preferable to WinXP (though that's personal
prejudice -- from a technical point of view, they are equal). The
order of prefence from best to worst would be:

Win2K/WinXP
Win NT 4
Win98/ME
Win95

It's never a good idea to have any workstation connecting to a
lesser version of Windows, unless it's the two pairs that I
consider equal (i.e., WinXP to Win2K is fine, as is WinME to
Win98).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #3

P: n/a
"Marc B" <mb******@hotmail.com> wrote:
Also, how safe is it to have different operating systems accessing the
backend? Is one better off having all PCs using the same operating system?


You do *NOT* want to use Win NT 4.0/2000/XP clients accessing an MDB on a Win 9x/ME
server. MS specifically recommends against this. Win 9x/ME clients to a Win 9x/ME
server or Win NT 4.0/2000/XP server is just fine.

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
Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.