R
ReidarT
Are there any limitations by using a backend-database connected through an
ODBC-connection and how is the performance?
regards
reidarT
ODBC-connection and how is the performance?
regards
reidarT
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
B
Billy Yao [MSFT]
Hi ReidarT,
Thank you for posting in the community. My name is Billy and it's my
pleasure to assist you with this issue.
From your description, I understand that you would like to know some
existed limitations when you use an ODBC Driver for Access to connect a
backend database. Additionally, performance is also your concern using this
method. Have I fully understood you? If there is anything I misunderstood,
please feel free to let me know.
Based on my experience, it is recommended that one does not place Jet
database files (.mdb) under high user loads more than 15 instances.
Otherwise, you he receive the error message '-2147467259' indicates that
the database has been placed in a state by an unknown user that prevents it
from being opened or locked.
307640 PRB: Error -2147467259 When You Try to Open the Same MDB File from
http://support.microsoft.com/?id=307640
The workaround in the following article extends the retry delay for Jet so
that you can use additional instances.
However, it sacrifices the performance in some cases may be the most
importance thing for you. In this high user loads scenario for the
performance benefits, we recommend you use SQL Server Enterprise Edition or
Standard Edition so that you are allowed with more concurrent users and
instances.
=================
On the next place if you use an Access project (ADP), when you try to link
to a particular data source when you are using an Open Database
Connectivity (ODBC) File Data Source Name (File DSN) connection, you Cannot
Link Tables into the Access Project by Using an ODBC DSN connection.
For detailed information, please see the KB below:
287414 You Cannot Link Tables into a Microsoft Access Project by Using an
ODBC
http://support.microsoft.com/?id=287414
==================
Last but not the least, for the better performance and Jet engine threads
safety; I suggest you using Microsoft OLE DB Provider for Jet instead of
ODBC for Access. The reason why I prefer OLE DB Provider for Jet is as
below:
When going through our OLEDB provider, Jet 4.0 is thread safe, though we
are not really a true multi-threaded database engine. Jet spawns multiple
threads to do tasks in the background. For incoming threads, our OLEDB
provider basically caches the threads and manages them going to Jet, but
Jet can only process one thread at a time (kind of like Win3.X did time
slicing of multiple tasks).
Access ODBC Driver (ODBCJT32.dll) is generally not as thread-safe as JOLT
(Jet OLE DB Provider). Both the ODBC driver and the DAO code (and Access,
for that matter) use an expression service that is not thread safe and is
not tested on generic thread-safe scenarios. The ODBC driver has the most
testing of the three listed here, but it is not generally recommended for
ALL high-stress scenarios. Some multi-threaded scenarios will function
relatively well, but even those aren't "recommended".
JOLT is a bit better than these options because it has components that are
all supposed to be thread-safe (as opposed to "hoping" they are thread safe
in the scenarios customers use most). Even then, while JOLT will function
through IIS, that doesn't mean you should run your business on it. It is a
single-user/few-user database engine that works well for simple multi-user
scenarios. It does not scale well at all. So, if you are running many
threads against a single instance of the engine (say, an IIS scenario with
a lot of inserts, for example), you will get more conflicts when running
with Jet vs. SQL Server. That's the difference.
If you want to use Jet/JOLT for one of our shipping products where you
control all of the threads and have controlled usage patterns that work
well with Jet, you can most likely use JOLT/Jet to solve your problem.
People do this now in shipping boxes successfully. However, if you use
threads to encapsulate multiple users (i.e. as a scaling mechanism),
understand that you're going to run into lock conflicts, database bloating,
etc.
It is capable of running on multi-processor machines, but it won't take
advantage of the multiple CPU's.
When going through our OLEDB provider, Jet 4.0 is thread safe, though we
are not really a true multi-threaded database engine. Jet spawns multiple
threads to do tasks in the background. For incoming threads, our OLEDB
provider basically caches the threads and manages them going to Jet, but
Jet can only process one thread at a time (kind of like Win3.X did time
slicing of multiple tasks).
For more information on thread safety for DAO/Jet, I include the following
article for your further reference:
169395 PRB: Thread Safety for DAO/Jet
http://support.microsoft.com/?id=169395
========================
ReidarT, does this answer your question? Thank you for your patience and
cooperation. If there is anything more I can do to assist you, please feel
free to post it in the group. I am standing by to be of assistance.
Thank you for using MSDN Newsgroup!
Best regards,
Billy Yao
Microsoft Online Support
Thank you for posting in the community. My name is Billy and it's my
pleasure to assist you with this issue.
From your description, I understand that you would like to know some
existed limitations when you use an ODBC Driver for Access to connect a
backend database. Additionally, performance is also your concern using this
method. Have I fully understood you? If there is anything I misunderstood,
please feel free to let me know.
Based on my experience, it is recommended that one does not place Jet
database files (.mdb) under high user loads more than 15 instances.
Otherwise, you he receive the error message '-2147467259' indicates that
the database has been placed in a state by an unknown user that prevents it
from being opened or locked.
307640 PRB: Error -2147467259 When You Try to Open the Same MDB File from
http://support.microsoft.com/?id=307640
The workaround in the following article extends the retry delay for Jet so
that you can use additional instances.
However, it sacrifices the performance in some cases may be the most
importance thing for you. In this high user loads scenario for the
performance benefits, we recommend you use SQL Server Enterprise Edition or
Standard Edition so that you are allowed with more concurrent users and
instances.
=================
On the next place if you use an Access project (ADP), when you try to link
to a particular data source when you are using an Open Database
Connectivity (ODBC) File Data Source Name (File DSN) connection, you Cannot
Link Tables into the Access Project by Using an ODBC DSN connection.
For detailed information, please see the KB below:
287414 You Cannot Link Tables into a Microsoft Access Project by Using an
ODBC
http://support.microsoft.com/?id=287414
==================
Last but not the least, for the better performance and Jet engine threads
safety; I suggest you using Microsoft OLE DB Provider for Jet instead of
ODBC for Access. The reason why I prefer OLE DB Provider for Jet is as
below:
When going through our OLEDB provider, Jet 4.0 is thread safe, though we
are not really a true multi-threaded database engine. Jet spawns multiple
threads to do tasks in the background. For incoming threads, our OLEDB
provider basically caches the threads and manages them going to Jet, but
Jet can only process one thread at a time (kind of like Win3.X did time
slicing of multiple tasks).
Access ODBC Driver (ODBCJT32.dll) is generally not as thread-safe as JOLT
(Jet OLE DB Provider). Both the ODBC driver and the DAO code (and Access,
for that matter) use an expression service that is not thread safe and is
not tested on generic thread-safe scenarios. The ODBC driver has the most
testing of the three listed here, but it is not generally recommended for
ALL high-stress scenarios. Some multi-threaded scenarios will function
relatively well, but even those aren't "recommended".
JOLT is a bit better than these options because it has components that are
all supposed to be thread-safe (as opposed to "hoping" they are thread safe
in the scenarios customers use most). Even then, while JOLT will function
through IIS, that doesn't mean you should run your business on it. It is a
single-user/few-user database engine that works well for simple multi-user
scenarios. It does not scale well at all. So, if you are running many
threads against a single instance of the engine (say, an IIS scenario with
a lot of inserts, for example), you will get more conflicts when running
with Jet vs. SQL Server. That's the difference.
If you want to use Jet/JOLT for one of our shipping products where you
control all of the threads and have controlled usage patterns that work
well with Jet, you can most likely use JOLT/Jet to solve your problem.
People do this now in shipping boxes successfully. However, if you use
threads to encapsulate multiple users (i.e. as a scaling mechanism),
understand that you're going to run into lock conflicts, database bloating,
etc.
It is capable of running on multi-processor machines, but it won't take
advantage of the multiple CPU's.
When going through our OLEDB provider, Jet 4.0 is thread safe, though we
are not really a true multi-threaded database engine. Jet spawns multiple
threads to do tasks in the background. For incoming threads, our OLEDB
provider basically caches the threads and manages them going to Jet, but
Jet can only process one thread at a time (kind of like Win3.X did time
slicing of multiple tasks).
For more information on thread safety for DAO/Jet, I include the following
article for your further reference:
169395 PRB: Thread Safety for DAO/Jet
http://support.microsoft.com/?id=169395
========================
ReidarT, does this answer your question? Thank you for your patience and
cooperation. If there is anything more I can do to assist you, please feel
free to post it in the group. I am standing by to be of assistance.
Thank you for using MSDN Newsgroup!
Best regards,
Billy Yao
Microsoft Online Support
R
ReidarT
Thanks alot
I have a few questions
1. Is it a reasonable solution to use an sql backend and connect to the
sql-database through ODBC? or
2. Do I need to make an ADP-project of my existing access frontend database
to connect to the sql-backend?
regards
reidarT
I have a few questions
1. Is it a reasonable solution to use an sql backend and connect to the
sql-database through ODBC? or
2. Do I need to make an ADP-project of my existing access frontend database
to connect to the sql-backend?
regards
reidarT
"Billy Yao [MSFT]" said:Hi ReidarT,
Thank you for posting in the community. My name is Billy and it's my
pleasure to assist you with this issue.
From your description, I understand that you would like to know some
existed limitations when you use an ODBC Driver for Access to connect a
backend database. Additionally, performance is also your concern using this
method. Have I fully understood you? If there is anything I misunderstood,
please feel free to let me know.
Based on my experience, it is recommended that one does not place Jet
database files (.mdb) under high user loads more than 15 instances.
Otherwise, you he receive the error message '-2147467259' indicates that
the database has been placed in a state by an unknown user that prevents it
from being opened or locked.
307640 PRB: Error -2147467259 When You Try to Open the Same MDB File from
http://support.microsoft.com/?id=307640
The workaround in the following article extends the retry delay for Jet so
that you can use additional instances.
However, it sacrifices the performance in some cases may be the most
importance thing for you. In this high user loads scenario for the
performance benefits, we recommend you use SQL Server Enterprise Edition or
Standard Edition so that you are allowed with more concurrent users and
instances.
=================
On the next place if you use an Access project (ADP), when you try to link
to a particular data source when you are using an Open Database
Connectivity (ODBC) File Data Source Name (File DSN) connection, you Cannot
Link Tables into the Access Project by Using an ODBC DSN connection.
For detailed information, please see the KB below:
287414 You Cannot Link Tables into a Microsoft Access Project by Using an
ODBC
http://support.microsoft.com/?id=287414
==================
Last but not the least, for the better performance and Jet engine threads
safety; I suggest you using Microsoft OLE DB Provider for Jet instead of
ODBC for Access. The reason why I prefer OLE DB Provider for Jet is as
below:
When going through our OLEDB provider, Jet 4.0 is thread safe, though we
are not really a true multi-threaded database engine. Jet spawns multiple
threads to do tasks in the background. For incoming threads, our OLEDB
provider basically caches the threads and manages them going to Jet, but
Jet can only process one thread at a time (kind of like Win3.X did time
slicing of multiple tasks).
Access ODBC Driver (ODBCJT32.dll) is generally not as thread-safe as JOLT
(Jet OLE DB Provider). Both the ODBC driver and the DAO code (and Access,
for that matter) use an expression service that is not thread safe and is
not tested on generic thread-safe scenarios. The ODBC driver has the most
testing of the three listed here, but it is not generally recommended for
ALL high-stress scenarios. Some multi-threaded scenarios will function
relatively well, but even those aren't "recommended".
JOLT is a bit better than these options because it has components that are
all supposed to be thread-safe (as opposed to "hoping" they are thread safe
in the scenarios customers use most). Even then, while JOLT will function
through IIS, that doesn't mean you should run your business on it. It is a
single-user/few-user database engine that works well for simple multi-user
scenarios. It does not scale well at all. So, if you are running many
threads against a single instance of the engine (say, an IIS scenario with
a lot of inserts, for example), you will get more conflicts when running
with Jet vs. SQL Server. That's the difference.
If you want to use Jet/JOLT for one of our shipping products where you
control all of the threads and have controlled usage patterns that work
well with Jet, you can most likely use JOLT/Jet to solve your problem.
People do this now in shipping boxes successfully. However, if you use
threads to encapsulate multiple users (i.e. as a scaling mechanism),
understand that you're going to run into lock conflicts, database bloating,
etc.
It is capable of running on multi-processor machines, but it won't take
advantage of the multiple CPU's.
When going through our OLEDB provider, Jet 4.0 is thread safe, though we
are not really a true multi-threaded database engine. Jet spawns multiple
threads to do tasks in the background. For incoming threads, our OLEDB
provider basically caches the threads and manages them going to Jet, but
Jet can only process one thread at a time (kind of like Win3.X did time
slicing of multiple tasks).
For more information on thread safety for DAO/Jet, I include the following
article for your further reference:
169395 PRB: Thread Safety for DAO/Jet
http://support.microsoft.com/?id=169395
========================
ReidarT, does this answer your question? Thank you for your patience and
cooperation. If there is anything more I can do to assist you, please feel
free to post it in the group. I am standing by to be of assistance.
Thank you for using MSDN Newsgroup!
Best regards,
Billy Yao
Microsoft Online Support
A
Albert D. Kallal
ReidarT said:Thanks alot
I have a few questions
1. Is it a reasonable solution to use an sql backend and connect to the
sql-database through ODBC? or
Sure, that can work well. This makes a lot of sense for existing appcltions.
You want to be VERY careful when you build a query that is based on two
linked tables. The real solution in these cases to create a view on the sql
server, and link to that.
2. Do I need to make an ADP-project of my existing access frontend database
to connect to the sql-backend?
No, you do not. However, using a adp project FORCES you to design your
application so that all data stays on the server. You don't have local
tables for example when using a adp project. Also, you do avoid performance
problems like the above example I gave when using a sql join with more then
one table. It is VERY hard to mess up the issue of sql joins and the like
when using a adp project. If you use ODBC, then close attention needs to be
taken for your queries etc.
So, you can get ODBC to sql server to perform well, but you just have to be
more careful then when using a adp project.
R
ReidarT
Thanks again for very good answers.
As I understand it, the best way for performance and correct handling of
views instead of queries, you use an adp-project.
1. Is there any performance differences between an adp project and an
access-database?
2. Would it be better to use vb.net where I compile the project, concerning
performance and stability?
regards
reidarT
As I understand it, the best way for performance and correct handling of
views instead of queries, you use an adp-project.
1. Is there any performance differences between an adp project and an
access-database?
2. Would it be better to use vb.net where I compile the project, concerning
performance and stability?
regards
reidarT
A
Albert D. Kallal
ReidarT said:Thanks again for very good answers.
As I understand it, the best way for performance and correct handling of
views instead of queries, you use an adp-project.
Yes. Of course, this assumes you are willing to setup and run and maintain
a database server.
1. Is there any performance differences between an adp project and an
access-database?
Do you mean just a regular JET file share compared to a server based adp
project? Well, likely the ADP project will perform better. However, if you
are talking about a ms-access odbc connection to sql server compared to a
adp, then if you write the access odbc application well, then you likely
will NOT notice any difference in performance.
2. Would it be better to use vb.net where I compile the project, concerning
performance and stability?
Hum, better performance? No, I don't .net will give you better performance.
A good performing ms-access application is possible with a file share, or a
ODBC connection to sql server, or a adp project. All of these choices you
have with ms-access can result in very good performance. If you have a poor
design, then the file share, the orb, the adp project, and the .net
application will ALL perform like crap. Most certainly .net can allow you
to build and design a 3 tiered system, and use web services. Using web
services could certainly reduce bandwidth requirements, but you would be
talking about a different design here. However, just using one platform over
the other does not instantly provide some magic performance increase. You
have to have good designs that minimize bandwidth and that takes developers
with a few years of experience regardless of what tools you use.
B
Billy Yao [MSFT]
Hi Reidar,
Thank you for your update and further quesion.
As Albert has pointed out that if you build a query that is based on two linked tables, you can
use ADP with views for performance benefits in the most cases. However, I should mention
that you do not need to use ADP project. It all depends on your needs and your scenarios
to make the Jet 4.0 Database in top working condition.
If the Jet Database engine cannot suit your needs, it's time to migrate to SQL Server for
better performance. In fact, Jet database is not intended to be used with high-stress (such
as IIS), 24x7 server applications (such as Web, commerce, transactional, and messaging
servers). Additionally, as to the aspect of the Integrity, Multi-users handling, high-
concurrency transactions, using ADP with the SQL Server backend database is also more
stable and fast.
For more information on performance and stability issue on a Jet database, please see the
following article which detailed describs when to use Jet database and when to migrate to
SQL Server:
303528 HOW TO: Keep a Jet 4.0 Database in Top Working Condition
http://support.microsoft.com/?id=303528
Best regards,
Billy Yao
Microsoft Online Support
Thank you for your update and further quesion.
As Albert has pointed out that if you build a query that is based on two linked tables, you can
use ADP with views for performance benefits in the most cases. However, I should mention
that you do not need to use ADP project. It all depends on your needs and your scenarios
to make the Jet 4.0 Database in top working condition.
If the Jet Database engine cannot suit your needs, it's time to migrate to SQL Server for
better performance. In fact, Jet database is not intended to be used with high-stress (such
as IIS), 24x7 server applications (such as Web, commerce, transactional, and messaging
servers). Additionally, as to the aspect of the Integrity, Multi-users handling, high-
concurrency transactions, using ADP with the SQL Server backend database is also more
stable and fast.
For more information on performance and stability issue on a Jet database, please see the
following article which detailed describs when to use Jet database and when to migrate to
SQL Server:
303528 HOW TO: Keep a Jet 4.0 Database in Top Working Condition
http://support.microsoft.com/?id=303528
Best regards,
Billy Yao
Microsoft Online Support
B
Billy Yao [MSFT]
============================================
From: Reidar Thorsvik [mailto:[email protected]]
To: Bin Yao (Intl Vendor)
Subject: SV: Microsoft has updated your Newsgroup post: < BackEnd database
through ODBC-connection >
I would like to have some more information on using SQL-database as
backend-database through ODBC-connection.
regards
Reidar Thorsvik
============================================
Hi Reidar
Thanks for letting us know you need furture information on using
SQL-database as backend-database through ODBC-connection. Also thanks for
your patience and kind understanding that it's better to post in the group
for community benefits and the problems quick response as well.
As we known, ODBC is Microsoft's strategic API for database connectivity.
The ODBC API specification is based on a CLI spec developed by the SQL
Access Group (SAG), which is a consortium of various industries, including
Microsoft. With ODBC, an application can be written in an interoperable
fashion to connect to a number of back-ends, as long as there is a driver
available for that back-end such as SQL Server.
Here I found sources of information on this field, hoping they will suit
your needs and simplify your work:
209551 ACC2000: Tips for Optimizing Queries on Attached SQL Tables
http://support.microsoft.com/?id=209551
210319 ACC2000: How to Trap ODBC Logon Error Messages
http://support.microsoft.com/?id=210319
147814 HOWTO: Retrieve Multiple Result Sets from a Stored Procedure
http://support.microsoft.com/?id=147814
303528 HOW TO: Keep a Jet 4.0 Database in Top Working Condition
http://support.microsoft.com/?id=303528
For more information on how People using SQL-database as backend-database
through ODBC-connection, the following article is also very useful and I
include them for your reference:
********** The Third Party Disclaimer ************
This document contains references to a third party World Wide Web site.
Microsoft is providing this information as a convenience to you. Microsoft
does not control these sites and has not tested any software or information
found on these sites; therefore, Microsoft cannot make any representations
regarding the quality, safety, or suitability of any software or
information found there. There are inherent dangers in the use of any
software found on the Internet, and Microsoft cautions you to make sure
that you completely understand the risk before retrieving any software from
the Internet.
********** End Of Disclaimer *************
Jumping from Access 2002 to SQL Server 2000
-------------------------------------------
http://groups.google.com/groups?q=ODBC+and+connection+and+"SQl+Server"+a
nd+database+and+back-end+access+front-end&start=10&hl=zh-CN&lr=&ie=UTF-8&oe=
UTF-8&selm=e1UD8.6657%24TJ6.691941%40news20.bellglobal.com&rnum=18
Access DB conversion to SQL server DB
-------------------------------------
http://groups.google.com/groups?q=ODBC+and+connection+and+"SQl+Server"+a
nd+database+and+back-end+access+front-end&start=10&hl=zh-CN&lr=&ie=UTF-8&oe=
UTF-8&selm=2d9c2094.0107300944.1bf17226%40posting.google.com&rnum=13
Does ODBC to SQL work in ACCESS 97
----------------------------------
http://groups.google.com/groups?hl=zh-CN&lr=&ie=UTF-8&oe=UTF-8&threadm=8sues
e%24ecj%241%40plutonium.btinternet.com&rnum=4&prev=/groups%3Fq%3DODBC%2Band%
2Bconnection%2Band%2B%2522SQl%2BServer%2522%2Band%2Bdatabase%2Band%2Bback-en
d%2Baccess%2Bfront-end%26hl%3Dzh-CN%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm
%3D8suese%2524ecj%25241%2540plutonium.btinternet.com%26rnum%3D4
ACCESS97 Front-End to SQL Server 7 Back-End Password Process
------------------------------------------------------------
http://groups.google.com/groups?hl=zh-CN&lr=&ie=UTF-8&oe=UTF-8&threadm=YVXt6
..463344%24ge4.161917549%40news2.rdc2.tx.home.com&rnum=7&prev=/groups%3Fq%3DO
DBC%2Band%2Bconnection%2Band%2B%2522SQl%2BServer%2522%2Band%2Bdatabase%2Band
%2Bback-end%2Baccess%2Bfront-end%26hl%3Dzh-CN%26lr%3D%26ie%3DUTF-8%26oe%3DUT
F-8%26selm%3DYVXt6.463344%2524ge4.161917549%2540news2.rdc2.tx.home.com%26rnu
m%3D7
Best regards,
Billy Yao
Microsoft Online Support
From: Reidar Thorsvik [mailto:[email protected]]
To: Bin Yao (Intl Vendor)
Subject: SV: Microsoft has updated your Newsgroup post: < BackEnd database
through ODBC-connection >
I would like to have some more information on using SQL-database as
backend-database through ODBC-connection.
regards
Reidar Thorsvik
============================================
Hi Reidar
Thanks for letting us know you need furture information on using
SQL-database as backend-database through ODBC-connection. Also thanks for
your patience and kind understanding that it's better to post in the group
for community benefits and the problems quick response as well.
As we known, ODBC is Microsoft's strategic API for database connectivity.
The ODBC API specification is based on a CLI spec developed by the SQL
Access Group (SAG), which is a consortium of various industries, including
Microsoft. With ODBC, an application can be written in an interoperable
fashion to connect to a number of back-ends, as long as there is a driver
available for that back-end such as SQL Server.
Here I found sources of information on this field, hoping they will suit
your needs and simplify your work:
209551 ACC2000: Tips for Optimizing Queries on Attached SQL Tables
http://support.microsoft.com/?id=209551
210319 ACC2000: How to Trap ODBC Logon Error Messages
http://support.microsoft.com/?id=210319
147814 HOWTO: Retrieve Multiple Result Sets from a Stored Procedure
http://support.microsoft.com/?id=147814
303528 HOW TO: Keep a Jet 4.0 Database in Top Working Condition
http://support.microsoft.com/?id=303528
For more information on how People using SQL-database as backend-database
through ODBC-connection, the following article is also very useful and I
include them for your reference:
********** The Third Party Disclaimer ************
This document contains references to a third party World Wide Web site.
Microsoft is providing this information as a convenience to you. Microsoft
does not control these sites and has not tested any software or information
found on these sites; therefore, Microsoft cannot make any representations
regarding the quality, safety, or suitability of any software or
information found there. There are inherent dangers in the use of any
software found on the Internet, and Microsoft cautions you to make sure
that you completely understand the risk before retrieving any software from
the Internet.
********** End Of Disclaimer *************
Jumping from Access 2002 to SQL Server 2000
-------------------------------------------
http://groups.google.com/groups?q=ODBC+and+connection+and+"SQl+Server"+a
nd+database+and+back-end+access+front-end&start=10&hl=zh-CN&lr=&ie=UTF-8&oe=
UTF-8&selm=e1UD8.6657%24TJ6.691941%40news20.bellglobal.com&rnum=18
Access DB conversion to SQL server DB
-------------------------------------
http://groups.google.com/groups?q=ODBC+and+connection+and+"SQl+Server"+a
nd+database+and+back-end+access+front-end&start=10&hl=zh-CN&lr=&ie=UTF-8&oe=
UTF-8&selm=2d9c2094.0107300944.1bf17226%40posting.google.com&rnum=13
Does ODBC to SQL work in ACCESS 97
----------------------------------
http://groups.google.com/groups?hl=zh-CN&lr=&ie=UTF-8&oe=UTF-8&threadm=8sues
e%24ecj%241%40plutonium.btinternet.com&rnum=4&prev=/groups%3Fq%3DODBC%2Band%
2Bconnection%2Band%2B%2522SQl%2BServer%2522%2Band%2Bdatabase%2Band%2Bback-en
d%2Baccess%2Bfront-end%26hl%3Dzh-CN%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm
%3D8suese%2524ecj%25241%2540plutonium.btinternet.com%26rnum%3D4
ACCESS97 Front-End to SQL Server 7 Back-End Password Process
------------------------------------------------------------
http://groups.google.com/groups?hl=zh-CN&lr=&ie=UTF-8&oe=UTF-8&threadm=YVXt6
..463344%24ge4.161917549%40news2.rdc2.tx.home.com&rnum=7&prev=/groups%3Fq%3DO
DBC%2Band%2Bconnection%2Band%2B%2522SQl%2BServer%2522%2Band%2Bdatabase%2Band
%2Bback-end%2Baccess%2Bfront-end%26hl%3Dzh-CN%26lr%3D%26ie%3DUTF-8%26oe%3DUT
F-8%26selm%3DYVXt6.463344%2524ge4.161917549%2540news2.rdc2.tx.home.com%26rnu
m%3D7
Best regards,
Billy Yao
Microsoft Online Support