Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Access 2000 transactions in ASP 1
- Thread starter Deadline
- Start date
-
1
- #2
dilettante
MIS
The answer is No and Yes.
Don't you hate that!
First, my No:
:-( "Because an Access database (.mdb) is a file-server system, it must load the Jet database engine locally to process queries on the client."
And your IIS server is the client here, not your user's browser machine.
This means there is no way for DTC (MTS doesn't actually handle distributed transactions itself) to "get its hands on" a .mdb file. Also, Access doesn't do any journaling or auditing or logging of transactions - so how would you roll a transaction back???
And if you aren't doing distributed transactions, why are you using ASP transactions? This would be sheer overhead to no purpose.
Hey FoxPro is in the same boat, prob'ly worse.
But as for my qualified Yes:
"Access project files also support creating databases by using Microsoft Data Engine (MSDE)."
You need SQL Server (or MSDE, which is a stripped version of SQL Server, but a real database with a remote database engine). You can get by using MSDE without having a SQL Server DBA around - though it is still a bit more complex than using Jet.
See File-Server vs. Client/Server. This contains some useful information, and some good diagrams that unfortunately you need to look at carefully.
P.S.
I also heard somewhere once (don't you love it?) that somebody made some 3rd party thing to front-end a box running Access' Jet engine so it could be accessed remotely. But I still doubt that it would do transaction rollback. I think it was some kind of "shim" to let a Unix box get to an Access database on an NT box.
Hope this helps!
P.P.S.
I've had situations where the user DEMANDED to have an Access database, but the data they wanted was involved in distributed transactions. It is a mess.
One time we had to cave in. We ended up using SQL Server for the real database (along with the mainframe database that was also involved in the transactions), and forced quiet points at 8AM, 11:30AM, 2:30PM, and 5:10PM (don't ask). We shut down the web application's updates and replicated the stuff the user wanted into an Access database with a VB program.
The VB program was run as a scheduled task on a Win9x machine with a share the user could get to. It acted as a web client (browser) to the ASP application, and sent a special secured request to set a session variable that blocked database updates by "real" web users. Then it copied the data from SQL Server to the 9x machine's Access database in the shared folder, then it did another special request to turn updates back on. The data volume was small enough that the web users didn't get too upset - took about two minutes - and they could do "inquiry" stuff during those two minutes (extra work in the ASP pages of course).
The network security guys HATED it.
Yecch! I hope there is a better way to do this. We just made most of these kinds of people get to the SQL Server database using Access as a client. Still a security nightmare, but what isn't?
Don't you hate that!
First, my No:
:-( "Because an Access database (.mdb) is a file-server system, it must load the Jet database engine locally to process queries on the client."
And your IIS server is the client here, not your user's browser machine.
This means there is no way for DTC (MTS doesn't actually handle distributed transactions itself) to "get its hands on" a .mdb file. Also, Access doesn't do any journaling or auditing or logging of transactions - so how would you roll a transaction back???
And if you aren't doing distributed transactions, why are you using ASP transactions? This would be sheer overhead to no purpose.
Hey FoxPro is in the same boat, prob'ly worse.
But as for my qualified Yes:
"Access project files also support creating databases by using Microsoft Data Engine (MSDE)."You need SQL Server (or MSDE, which is a stripped version of SQL Server, but a real database with a remote database engine). You can get by using MSDE without having a SQL Server DBA around - though it is still a bit more complex than using Jet.
See File-Server vs. Client/Server. This contains some useful information, and some good diagrams that unfortunately you need to look at carefully.
P.S.
I also heard somewhere once (don't you love it?) that somebody made some 3rd party thing to front-end a box running Access' Jet engine so it could be accessed remotely. But I still doubt that it would do transaction rollback. I think it was some kind of "shim" to let a Unix box get to an Access database on an NT box.
Hope this helps!
P.P.S.
I've had situations where the user DEMANDED to have an Access database, but the data they wanted was involved in distributed transactions. It is a mess.
One time we had to cave in. We ended up using SQL Server for the real database (along with the mainframe database that was also involved in the transactions), and forced quiet points at 8AM, 11:30AM, 2:30PM, and 5:10PM (don't ask). We shut down the web application's updates and replicated the stuff the user wanted into an Access database with a VB program.
The VB program was run as a scheduled task on a Win9x machine with a share the user could get to. It acted as a web client (browser) to the ASP application, and sent a special secured request to set a session variable that blocked database updates by "real" web users. Then it copied the data from SQL Server to the 9x machine's Access database in the shared folder, then it did another special request to turn updates back on. The data volume was small enough that the web users didn't get too upset - took about two minutes - and they could do "inquiry" stuff during those two minutes (extra work in the ASP pages of course).
The network security guys HATED it.
Yecch! I hope there is a better way to do this. We just made most of these kinds of people get to the SQL Server database using Access as a client. Still a security nightmare, but what isn't?
- Thread starter
- #3
Hi, dilettante
Thank you very much. It was very helpful and it was like listening to an expert lecture.
The reason I needed transactions in the ASP page was because, I needed to update two tables... If either of them should fail, the operation needs to be rolled back.
Thank you very much yet again for your time and thoughts. I wonder why they haven't clearly mentioned about this issue in MSDN.
Thanks!
RR
Thank you very much. It was very helpful and it was like listening to an expert lecture.
The reason I needed transactions in the ASP page was because, I needed to update two tables... If either of them should fail, the operation needs to be rolled back.
Thank you very much yet again for your time and thoughts. I wonder why they haven't clearly mentioned about this issue in MSDN.
Thanks!
RR
dilettante
MIS
I assumed you must have had a good reason, you seemed to be after a concise answer and I went on and on... and on.
I had called a buddy to confirm a lot of this, and by the time I got back on to write back to you it was late, and so being tired I rambled on.
Maybe you should consider MSDE for what you're doing if it is really critical.
I had called a buddy to confirm a lot of this, and by the time I got back on to write back to you it was late, and so being tired I rambled on.
Maybe you should consider MSDE for what you're doing if it is really critical.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
