Hi,
I have an Access database and am having an ASP.NEt application written for
it. It is almost complete. I have a hosting company that I signed up with
a month ago but before I did anything I asked them if Access and ASP.NET
would work on their servers, they said yes so I bought in. Now they are
saying my application wont work on their servers using MSaccess and I can
only use SQL or asp 3.0. They are saying Microsoft is trying to keep Ms
Access as a desktop application. The database is done, and the app is
almost done. I have paid alot of money for this application. What are my
options here?
How hard is it to convert an Access Database to SQL? What ramifications
does this have on the ASP.NET part?
How hard is it to convert to asp 3.0?
I was also told XML would work. DOnt know anything about it.
What about other hosts?
Any other options?
I just cant believe this.
Any help and insight would be greatly appreciated.
Cory
25  4327 
Please see the recent thread underway on this subject here at
comp.databases.ms-access.
On Wed, 07 Jan 2004 04:56:55 GMT, "cory" <no***@here.com> wrote: Hi,
I have an Access database and am having an ASP.NEt application written for
it. It is almost complete. I have a hosting company that I signed up with
a month ago but before I did anything I asked them if Access and ASP.NET
would work on their servers, they said yes so I bought in. Now they are
saying my application wont work on their servers using MSaccess and I can
only use SQL or asp 3.0. They are saying Microsoft is trying to keep Ms
Access as a desktop application. The database is done, and the app is
almost done. I have paid alot of money for this application. What are my
options here?
How hard is it to convert an Access Database to SQL? What ramifications
does this have on the ASP.NET part?
How hard is it to convert to asp 3.0?
I was also told XML would work. DOnt know anything about it.
What about other hosts?
Any other options?
I just cant believe this.
Any help and insight would be greatly appreciated.
Cory
Converting an Access data structure to a SQL Server structure can be
difficult, depending on how the tables were designed and built. There are
tools available to do this, but I generally use the Data Transformation
Service if going to MS SQL Server.
From what I've heard, ASP 3.0 provides much poorer performance than ASP.net.
NOt sure about coverting between the two, you'll probably need to ask that
in an ASP group ... I've merely dabbled in ASP.NET
XML is a method to transfer data between platforms using formatted
text-based streams. Your data provider (i.e. your database) would send you
an XML document, and your application would take/convert/use that XML
document to "read" the data sent by the provider.
There are quite a few hosts that will support Access databases ... Google
should return a good list. However, your ISP service is not entirely
incorrect in their views. Most find that, unless your web site experiences
very low traffic, your Access db will quickly not be up to the task. My ISP
recently stopped supporting Access dbs simply because of the problems they
were having with congestion, performance issues (server tied up with
Jet/Access requests) and complaints from their users of lost/corrupted
databases. If my site were critical to my business, and I couldn't afford to
lose the time spent in restoring from my backup, then I'd certainly consider
going the SQL route ...
--
Scott McDaniel
CS Computer Software
Visual Basic - Access - Sql Server - ASP
"cory" <no***@here.com> wrote in message
news:rkMKb.86812$6b2.26807@edtnps84... Hi,
I have an Access database and am having an ASP.NEt application written for
it. It is almost complete. I have a hosting company that I signed up
with a month ago but before I did anything I asked them if Access and ASP.NET
would work on their servers, they said yes so I bought in. Now they are
saying my application wont work on their servers using MSaccess and I can
only use SQL or asp 3.0. They are saying Microsoft is trying to keep Ms
Access as a desktop application. The database is done, and the app is
almost done. I have paid alot of money for this application. What are my
options here?
How hard is it to convert an Access Database to SQL? What ramifications
does this have on the ASP.NET part?
How hard is it to convert to asp 3.0?
I was also told XML would work. DOnt know anything about it.
What about other hosts?
Any other options?
I just cant believe this.
Any help and insight would be greatly appreciated.
Cory
Since your application is developed in ASP.NET + MS Access...here are some
thought:
1. Convert DB from Access to Sql Server may be fairly easy, or may be quite
some work, depending on how the db is designed. Tables can be easily
transferred to SQL server, while queries are not. So, if the Access DB and
your app use a lot of queries in Access, you are having trouble to convert
them to either stored procedures in SQL server, or dynamic SQL statement in
your app.
2. Since the app is .NET app, I believe that the data access is based on
ADO.NET, not old ADO/DAO thing, thus, OleDB namespace in .NET is used to
access data in Jet database (Access database). Although OleDB namespace
works with SQL Server, you really should use SqlClient namespace to access
data in SQL Server, SqlClient namespace is specifically designed and
optimized in ADO.NET for SQL Server.
3. Go back to ASP.3.0 does not change the fact that Access is basically
designed as desktop database. Convert ASP.NET to ASP 3.0 may lead to entire
application re-written because of the different application
structure/approach in .NET and pre-.NET technology.
IMO, find a ISP that provides ASP.NET + Access DB service; or convert Access
DB to Sql Server, after all, a server based db is more suitable for web app.
"cory" <no***@here.com> wrote in message
news:rkMKb.86812$6b2.26807@edtnps84... Hi,
I have an Access database and am having an ASP.NEt application written for
it. It is almost complete. I have a hosting company that I signed up
with a month ago but before I did anything I asked them if Access and ASP.NET
would work on their servers, they said yes so I bought in. Now they are
saying my application wont work on their servers using MSaccess and I can
only use SQL or asp 3.0. They are saying Microsoft is trying to keep Ms
Access as a desktop application. The database is done, and the app is
almost done. I have paid alot of money for this application. What are my
options here?
How hard is it to convert an Access Database to SQL? What ramifications
does this have on the ASP.NET part?
How hard is it to convert to asp 3.0?
I was also told XML would work. DOnt know anything about it.
What about other hosts?
Any other options?
I just cant believe this.
Any help and insight would be greatly appreciated.
Cory
I feel your pain, so here's a thought...
Let me take a look at your existing Access database, and I'll give you a
free, no obligation time estimate on the conversion to SQL Server. I've
done a few of these recently...the most complex took 57 hours and included a
learning curve I won;t have to climb again...
You can reach me by emailing Kevin [at] 3NF-inc {dot} com. You will get a
SPAMArrest verification email in reply.
--
Kevin Hill
President
3NF Consulting www.3nf-inc.com/NewsGroups.htm
"cory" <no***@here.com> wrote in message
news:rkMKb.86812$6b2.26807@edtnps84... Hi,
I have an Access database and am having an ASP.NEt application written for
it. It is almost complete. I have a hosting company that I signed up
with a month ago but before I did anything I asked them if Access and ASP.NET
would work on their servers, they said yes so I bought in. Now they are
saying my application wont work on their servers using MSaccess and I can
only use SQL or asp 3.0. They are saying Microsoft is trying to keep Ms
Access as a desktop application. The database is done, and the app is
almost done. I have paid alot of money for this application. What are my
options here?
How hard is it to convert an Access Database to SQL? What ramifications
does this have on the ASP.NET part?
How hard is it to convert to asp 3.0?
I was also told XML would work. DOnt know anything about it.
What about other hosts?
Any other options?
I just cant believe this.
Any help and insight would be greatly appreciated.
Cory
I write in ASP 3.0 and use MsAccess DB's but for very small traffic
sites. I agree if you expect any traffic you should go ahead and move
up to MySQL or SQLserver whichever the host allows you to use.
Since your data isn't too far along your developer should be able to
do the switch over for you.
no********@RemoveThis.shaw.ca (Norman Yuan) wrote in
<XBWKb.15883$X%5.13218@pd7tw2no>: IMO, find a ISP that provides ASP.NET + Access DB service; or
convert Access DB to Sql Server, after all, a server based db is
more suitable for web app.
Every single web app should use a server-based db?
Or do you really mean "a server-based db is more suitable for
medium- to large-volume websites, especially with large populations
of simultaneous connections and heavy write load. On the other
hand, smaller numbers of simultaneous connections and read-only web
pages can be run very well against Jet back ends."
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Wed, 07 Jan 2004 20:10:13 GMT, dX********@bway.net.invalid (David W.
Fenton) wrote: no********@RemoveThis.shaw.ca (Norman Yuan) wrote in
<XBWKb.15883$X%5.13218@pd7tw2no>:
IMO, find a ISP that provides ASP.NET + Access DB service; or
convert Access DB to Sql Server, after all, a server based db is
more suitable for web app.
Every single web app should use a server-based db?
Or do you really mean "a server-based db is more suitable for
medium- to large-volume websites, especially with large populations
of simultaneous connections and heavy write load. On the other
hand, smaller numbers of simultaneous connections and read-only web
pages can be run very well against Jet back ends."
What I've heard from people who have done it is that Web apps bog down with
Access back-ends under pretty light loads because Jet is not multi-threaded.
The concensus seems to be that you'll eventually need a server back-end for
most Web apps, so it's easier if you go ahead and start out that way.
Amen
--
Jerry Boone
Analytical Technologies, Inc. http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:rq********************************@4ax.com... On Wed, 07 Jan 2004 20:10:13 GMT, dX********@bway.net.invalid (David W.
Fenton) wrote:
no********@RemoveThis.shaw.ca (Norman Yuan) wrote in
<XBWKb.15883$X%5.13218@pd7tw2no>:
IMO, find a ISP that provides ASP.NET + Access DB service; or
convert Access DB to Sql Server, after all, a server based db is
more suitable for web app.
Every single web app should use a server-based db?
Or do you really mean "a server-based db is more suitable for
medium- to large-volume websites, especially with large populations
of simultaneous connections and heavy write load. On the other
hand, smaller numbers of simultaneous connections and read-only web
pages can be run very well against Jet back ends."
What I've heard from people who have done it is that Web apps bog down
with Access back-ends under pretty light loads because Jet is not
multi-threaded. The concensus seems to be that you'll eventually need a server back-end
for most Web apps, so it's easier if you go ahead and start out that way.
"Steve Jorgensen" wrote What I've heard from people who have
done it is that Web apps bog down with
Access back-ends under pretty light loads
What's a "pretty light load"? Would it be fewer concurrent users than can
use an Access multiuser application with satisfactory performance? I
seriously doubt it, and that number can be up to 100+. That's not enough for
"the next Amazon", but I would venture that few websites on the Net
consistently have enough users to put a strain on it.
because Jet is not multi-threaded.
Again, if that's not a problem with 75 concurrent users on a LAN, why would
it be a problem with 75 concurrent users on a website (short of the web
developers not knowing much about database and using it in an abominable
fashion)?
The concensus seems to be that you'll
eventually need a server back-end for
most Web apps, so it's easier if you go
ahead and start out that way.
That's a generalization, that, like many generalizations, can throw you
off-track -- I'd disagree that _most_ Web apps will outgrow a Jet database.
Some will, but many will not.
Use appropriate technologies... that's the ticket.
Larry Linson
Microsoft Access MVP
It is a large application and smalldatabase at the same time. I think there
are 25-30 tables. No queries or forms etc.
Just tables. It is meant for limited users. There may be 10-20 users
logged in at once at any given time. It is not ecommerce and is is not
intended to be marketed for the world to use. If I am lucky, I may get 100
users in the dbase in a few years. The web app is more read only meaning
the user cannot write to the database only an admin can and I am the only
admin right now. I felt Access was the right choice because I know Access
somewhat and I dont know SQL. at all. I like Access for the reporting
feature as this is very important to me for providing clients with their
info at the end of a project. It seems alot of people think all databases
habe world wide users, this is not the case. I have found a host that can
do this and the host I am with who said they could not is the ONLY one who
does not support this arrangement......I find this odd. Myhosting.com is
the company that cant do it so I am moving to another provider. I have it
in writing that this new host I am moving to can provide what I need 100%.
I may switch to SQL in the future and my programmer said this would take
about 50 hours to do....doe sthis sound right for the number of tables and
no queries?
Thanks for all help here
"Norman Yuan" <no********@RemoveThis.shaw.ca> wrote in message
news:XBWKb.15883$X%5.13218@pd7tw2no... Since your application is developed in ASP.NET + MS Access...here are some
thought:
1. Convert DB from Access to Sql Server may be fairly easy, or may be
quite some work, depending on how the db is designed. Tables can be easily
transferred to SQL server, while queries are not. So, if the Access DB and
your app use a lot of queries in Access, you are having trouble to convert
them to either stored procedures in SQL server, or dynamic SQL statement
in your app.
2. Since the app is .NET app, I believe that the data access is based on
ADO.NET, not old ADO/DAO thing, thus, OleDB namespace in .NET is used to
access data in Jet database (Access database). Although OleDB namespace
works with SQL Server, you really should use SqlClient namespace to access
data in SQL Server, SqlClient namespace is specifically designed and
optimized in ADO.NET for SQL Server.
3. Go back to ASP.3.0 does not change the fact that Access is basically
designed as desktop database. Convert ASP.NET to ASP 3.0 may lead to
entire application re-written because of the different application
structure/approach in .NET and pre-.NET technology.
IMO, find a ISP that provides ASP.NET + Access DB service; or convert
Access DB to Sql Server, after all, a server based db is more suitable for web
app.
On Thu, 08 Jan 2004 02:30:02 GMT, "Larry Linson" <bo*****@localhost.not>
wrote: "Steve Jorgensen" wrote
What I've heard from people who have
done it is that Web apps bog down with
Access back-ends under pretty light loads
What's a "pretty light load"? Would it be fewer concurrent users than can
use an Access multiuser application with satisfactory performance? I
seriously doubt it, and that number can be up to 100+. That's not enough for
"the next Amazon", but I would venture that few websites on the Net
consistently have enough users to put a strain on it.
because Jet is not multi-threaded.
Again, if that's not a problem with 75 concurrent users on a LAN, why would
it be a problem with 75 concurrent users on a website (short of the web
developers not knowing much about database and using it in an abominable
fashion)?
Aree you comparing Access/JET to ASP/JET? If so, they are not at all the same
thing. With Access, each user has their own instance of JET running queries.
That's like each user having a separate thread, and even a separate machine to
run the thread! The only issues are lock contention and network resources.
With a Web server, a single instance of JET must handle all requests from all
users, and it can only service one of them at a time. If my query takes 5
seconds, everyone waits 5 seconds. If the next request in the queue also
takes 5 seconds, someone else waits 10.
How long it would take depends entirely on the structure of the tables and
how complex the queries are. Simple select queries convert easily. More
complex queries need to be converte to stored procedures, which takes
longer.
My offer to look over your db still stands, and will always be there. :-)
--
Kevin Hill
President
3NF Consulting www.3nf-inc.com/NewsGroups.htm
"cory" <no***@here.com> wrote in message
news:EY3Lb.47946$Dm.7435@edtnps89... It is a large application and smalldatabase at the same time. I think
there are 25-30 tables. No queries or forms etc.
Just tables. It is meant for limited users. There may be 10-20 users
logged in at once at any given time. It is not ecommerce and is is not
intended to be marketed for the world to use. If I am lucky, I may get
100 users in the dbase in a few years. The web app is more read only meaning
the user cannot write to the database only an admin can and I am the only
admin right now. I felt Access was the right choice because I know Access
somewhat and I dont know SQL. at all. I like Access for the reporting
feature as this is very important to me for providing clients with their
info at the end of a project. It seems alot of people think all databases
habe world wide users, this is not the case. I have found a host that can
do this and the host I am with who said they could not is the ONLY one who
does not support this arrangement......I find this odd. Myhosting.com is
the company that cant do it so I am moving to another provider. I have it
in writing that this new host I am moving to can provide what I need 100%.
I may switch to SQL in the future and my programmer said this would take
about 50 hours to do....doe sthis sound right for the number of tables and
no queries?
Thanks for all help here
"Norman Yuan" <no********@RemoveThis.shaw.ca> wrote in message
news:XBWKb.15883$X%5.13218@pd7tw2no... Since your application is developed in ASP.NET + MS Access...here are
some thought:
1. Convert DB from Access to Sql Server may be fairly easy, or may be
quite some work, depending on how the db is designed. Tables can be easily
transferred to SQL server, while queries are not. So, if the Access DB
and your app use a lot of queries in Access, you are having trouble to
convert them to either stored procedures in SQL server, or dynamic SQL statement
in your app.
2. Since the app is .NET app, I believe that the data access is based on
ADO.NET, not old ADO/DAO thing, thus, OleDB namespace in .NET is used to
access data in Jet database (Access database). Although OleDB namespace
works with SQL Server, you really should use SqlClient namespace to
access data in SQL Server, SqlClient namespace is specifically designed and
optimized in ADO.NET for SQL Server.
3. Go back to ASP.3.0 does not change the fact that Access is basically
designed as desktop database. Convert ASP.NET to ASP 3.0 may lead to
entire application re-written because of the different application
structure/approach in .NET and pre-.NET technology.
IMO, find a ISP that provides ASP.NET + Access DB service; or convert
Access DB to Sql Server, after all, a server based db is more suitable for web
app.
Thanks for the clarification.
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:ld********************************@4ax.com... On Thu, 08 Jan 2004 02:30:02 GMT, "Larry Linson" <bo*****@localhost.not>
wrote:
"Steve Jorgensen" wrote
What I've heard from people who have
done it is that Web apps bog down with
Access back-ends under pretty light loads
What's a "pretty light load"? Would it be fewer concurrent users than can
use an Access multiuser application with satisfactory performance? I
seriously doubt it, and that number can be up to 100+. That's not enough
for"the next Amazon", but I would venture that few websites on the Net
consistently have enough users to put a strain on it.
because Jet is not multi-threaded.
Again, if that's not a problem with 75 concurrent users on a LAN, why
wouldit be a problem with 75 concurrent users on a website (short of the web
developers not knowing much about database and using it in an abominable
fashion)?
Aree you comparing Access/JET to ASP/JET? If so, they are not at all the
same thing. With Access, each user has their own instance of JET running
queries. That's like each user having a separate thread, and even a separate
machine to run the thread! The only issues are lock contention and network
resources.
With a Web server, a single instance of JET must handle all requests from
all users, and it can only service one of them at a time. If my query takes 5
seconds, everyone waits 5 seconds. If the next request in the queue also
takes 5 seconds, someone else waits 10. no****@nospam.nospam (Steve Jorgensen) wrote in
<rq********************************@4ax.com>: On Wed, 07 Jan 2004 20:10:13 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:
no********@RemoveThis.shaw.ca (Norman Yuan) wrote in
<XBWKb.15883$X%5.13218@pd7tw2no>:
IMO, find a ISP that provides ASP.NET + Access DB service; or
convert Access DB to Sql Server, after all, a server based db is
more suitable for web app.
Every single web app should use a server-based db?
Or do you really mean "a server-based db is more suitable for
medium- to large-volume websites, especially with large
populations of simultaneous connections and heavy write load. On
the other hand, smaller numbers of simultaneous connections and
read-only web pages can be run very well against Jet back ends."
What I've heard from people who have done it is that Web apps bog
down with Access back-ends under pretty light loads because Jet is
not multi-threaded. The concensus seems to be that you'll
eventually need a server back-end for most Web apps, so it's
easier if you go ahead and start out that way.
Is that people who are being careful to conserve connections in
their ASP code?
MichKa used to explain how his website was very robust with 100s of
thousands of hits per day, and a Jet back end.
As to multi-threading, I think the question is *thread-safe*, and
MichKa has said, I believe, that Jet accessed via DAO is not
thread-safe, whereas through ADO it *is* thread-safe.
Because of that, my surmise is that ASP is one of the cases where
ADO is better for use with Jet than its native DAO.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Thu, 08 Jan 2004 22:12:18 GMT, dX********@bway.net.invalid (David W.
Fenton) wrote:
.... What I've heard from people who have done it is that Web apps bog
down with Access back-ends under pretty light loads because Jet is
not multi-threaded. The concensus seems to be that you'll
eventually need a server back-end for most Web apps, so it's
easier if you go ahead and start out that way.
Is that people who are being careful to conserve connections in
their ASP code?
MichKa used to explain how his website was very robust with 100s of
thousands of hits per day, and a Jet back end.
That's an opinion, I'd be inclinded to believe.
As to multi-threading, I think the question is *thread-safe*, and
MichKa has said, I believe, that Jet accessed via DAO is not
thread-safe, whereas through ADO it *is* thread-safe.
That's interesting to know. That would make a big difference.
Because of that, my surmise is that ASP is one of the cases where
ADO is better for use with Jet than its native DAO.
My opinion has been that, in Access there are usually more reasons to use DAO
than ADO. Outside of Access, there are usually more reasons to use ADO than
DAO.
Have you or anyone else been able to open mdb's while they are being used
and not get a "Page cannot be displayed.... Jet database is in use" error?
I spent a lot of time posting and trying to work around this with no
success. Resorted to copy, modify and replace, or web based updates that
use sql statements. This is quite different with Sql Server and other
engines.
If no one has a "viable" answer to this then I would say the hell with mdb's
on the web when they need to be modified regularly by a developer and
updated directly by users.
Don't even bother replying unless you have a connection string or proven
odbc property... or something similar, pretend for a minute that your a
developer and need to have the database open while your building your ASP
pages.
This may be better in ASP.Net, but I haven't even given it a chance based on
past performance.
--
Jerry Boone
Analytical Technologies, Inc. http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:g8********************************@4ax.com... On Thu, 08 Jan 2004 22:12:18 GMT, dX********@bway.net.invalid (David W.
Fenton) wrote:
...What I've heard from people who have done it is that Web apps bog
down with Access back-ends under pretty light loads because Jet is
not multi-threaded. The concensus seems to be that you'll
eventually need a server back-end for most Web apps, so it's
easier if you go ahead and start out that way.
Is that people who are being careful to conserve connections in
their ASP code?
MichKa used to explain how his website was very robust with 100s of
thousands of hits per day, and a Jet back end.
That's an opinion, I'd be inclinded to believe.
As to multi-threading, I think the question is *thread-safe*, and
MichKa has said, I believe, that Jet accessed via DAO is not
thread-safe, whereas through ADO it *is* thread-safe.
That's interesting to know. That would make a big difference.
Because of that, my surmise is that ASP is one of the cases where
ADO is better for use with Jet than its native DAO.
My opinion has been that, in Access there are usually more reasons to use
DAO than ADO. Outside of Access, there are usually more reasons to use ADO
than DAO. no****@nospam.nospam (Steve Jorgensen) wrote in
<g8********************************@4ax.com>: On Thu, 08 Jan 2004 22:12:18 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:
...What I've heard from people who have done it is that Web apps
bog down with Access back-ends under pretty light loads because
Jet is not multi-threaded. The concensus seems to be that you'll
eventually need a server back-end for most Web apps, so it's
easier if you go ahead and start out that way.
Is that people who are being careful to conserve connections in
their ASP code?
MichKa used to explain how his website was very robust with 100s
of thousands of hits per day, and a Jet back end.
That's an opinion, I'd be inclinded to believe.
Well, it's MichKa, so it means a lot to me. I'm certain the design
of his website was super rock solid, as MichKa knows what he's
doing. I would expect he conserved his connections very carefully. As to multi-threading, I think the question is *thread-safe*, and
MichKa has said, I believe, that Jet accessed via DAO is not
thread-safe, whereas through ADO it *is* thread-safe.
That's interesting to know. That would make a big difference.
I hope I'm not misremembering. Nope: http://groups.google.com/groups?selm...06%40cpmsnbbsa
05&oe=UTF-8
says:
Jet 4.0 is threadsafe, as is the Jet OLE DB provider for
4.0.
Neither 3.5, nor any prior version, nor DAO of any version,
nor Access, is thread-safe.
There you have it. Because of that, my surmise is that ASP is one of the cases where
ADO is better for use with Jet than its native DAO.
My opinion has been that, in Access there are usually more reasons
to use DAO than ADO. Outside of Access, there are usually more
reasons to use ADO than DAO.
ADO is an interface to OLEDB, right? In ASP can't you use OLEDB
directly? And all bets are off in ASP.NET?
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Thu, 08 Jan 2004 06:16:27 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote: On Thu, 08 Jan 2004 02:30:02 GMT, "Larry Linson" <bo*****@localhost.not>
wrote:
"Steve Jorgensen" wrote
> What I've heard from people who have
> done it is that Web apps bog down with
> Access back-ends under pretty light loads
What's a "pretty light load"? Would it be fewer concurrent users than can
use an Access multiuser application with satisfactory performance? I
seriously doubt it, and that number can be up to 100+. That's not enough for
"the next Amazon", but I would venture that few websites on the Net
consistently have enough users to put a strain on it.
> because Jet is not multi-threaded.
Again, if that's not a problem with 75 concurrent users on a LAN, why would
it be a problem with 75 concurrent users on a website (short of the web
developers not knowing much about database and using it in an abominable
fashion)?
Aree you comparing Access/JET to ASP/JET? If so, they are not at all the same
thing. With Access, each user has their own instance of JET running queries.
That's like each user having a separate thread, and even a separate machine to
run the thread! The only issues are lock contention and network resources.
With a Web server, a single instance of JET must handle all requests from all
users, and it can only service one of them at a time. If my query takes 5
seconds, everyone waits 5 seconds. If the next request in the queue also
takes 5 seconds, someone else waits 10.
5 seconds is a *very* long query. But here is an interesting
article/discussion on that. http://www.15seconds.com/Issue/010514.htm
- Jim
On Thu, 08 Jan 2004 22:12:18 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote:
Because of that, my surmise is that ASP is one of the cases where
ADO is better for use with Jet than its native DAO.
AFIK, you can't use DAO with asp - only ADO. Classic ASP anyway.
- Jim
I don't think there is any reason to convert or to rewrite code or
change database. ASP.NET + Access works absolutely fine this is from
my practical experience. Only thing I see here is the ISP is not up to
dated. Find a good ISP that will help you get what you need.
Suvra
M6.Net www.m6.net
--
Windows 2003 hosting - ASP.NET, PHP, CGI, Perl, FP
SQL 2000, MS Access, Emails, Stats and more...
On Fri, 09 Jan 2004 19:04:29 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote: ji****@Notdatacentricsolutions.com (Jim Allensworth) wrote in
<3f****************@news.west.earthlink.net>:
On Thu, 08 Jan 2004 22:12:18 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:
Because of that, my surmise is that ASP is one of the cases where
ADO is better for use with Jet than its native DAO.
AFIK, you can't use DAO with asp - only ADO. Classic ASP anyway.
I should have said ODBC.
The URL you posted in another thread pretty clearly confirms the
other things I've said, that a Jet back end can handle far more
users if you conserve connections. It stands to reason, of course.
It is a case, though, where the introduction of ADO was a real
advance. Access with Jet data was *not* such a case -- that was a
case where ADO has no value whatsoever in the vast majority of
scenarios.
It is an important concept that with ASP - unlike Access - there is no
connection maintained. The database is hit and immediately released.
Assuming a reasonably well constructed SQL this is very fast - in the
fraction of a second neighborhood. Of course the server comes into
play as well. Along with properly indexed tables.
- Jim
Just what is the RSFast that is mentioned? I followed the link and it talked
about how to use it, but not exactly what it _is_ nor where/how one might
obtain it.
Larry
"Jim Allensworth" <ji****@Notdatacentricsolutions.com> wrote in message
news:3f****************@news.west.earthlink.net... On Thu, 08 Jan 2004 06:16:27 GMT, Steve Jorgensen
<no****@nospam.nospam> wrote:
On Thu, 08 Jan 2004 02:30:02 GMT, "Larry Linson" <bo*****@localhost.not>
wrote:
"Steve Jorgensen" wrote
> What I've heard from people who have
> done it is that Web apps bog down with
> Access back-ends under pretty light loads
What's a "pretty light load"? Would it be fewer concurrent users than
canuse an Access multiuser application with satisfactory performance? I
seriously doubt it, and that number can be up to 100+. That's not enough
for"the next Amazon", but I would venture that few websites on the Net
consistently have enough users to put a strain on it.
> because Jet is not multi-threaded.
Again, if that's not a problem with 75 concurrent users on a LAN, why
wouldit be a problem with 75 concurrent users on a website (short of the web
developers not knowing much about database and using it in an abominable
fashion)?
Aree you comparing Access/JET to ASP/JET? If so, they are not at all the
samething. With Access, each user has their own instance of JET running
queries.That's like each user having a separate thread, and even a separate
machine torun the thread! The only issues are lock contention and network
resources.
With a Web server, a single instance of JET must handle all requests from
allusers, and it can only service one of them at a time. If my query takes
5seconds, everyone waits 5 seconds. If the next request in the queue also
takes 5 seconds, someone else waits 10.
5 seconds is a *very* long query. But here is an interesting
article/discussion on that.
http://www.15seconds.com/Issue/010514.htm
- Jim
On Sat, 10 Jan 2004 01:04:32 GMT, "Larry Linson"
<bo*****@localhost.not> wrote: Just what is the RSFast that is mentioned? I followed the link and it talked
about how to use it, but not exactly what it _is_ nor where/how one might
obtain it.
It's an ASP library that facilitates caching. Here is an
intro/overview to it... http://www.learnasp.com/learn/rsfast-intro.asp
Here is the actual library ... http://www.learnasp.com/learn/rsfast-lib.asp
I haven't used it, but it looks quite interesting - especially for us
Jet users.
- Jim
Thanks, Jim. I will take a closer look at it. It may be just what is needed
for some website enhancements for my user group.
Larry
"Jim Allensworth" <Ji****@NOTdatacentricsolutions.com> wrote in message
news:3f***************@netnews.comcast.net... On Sat, 10 Jan 2004 01:04:32 GMT, "Larry Linson"
<bo*****@localhost.not> wrote:
Just what is the RSFast that is mentioned? I followed the link and it
talkedabout how to use it, but not exactly what it _is_ nor where/how one might
obtain it.
It's an ASP library that facilitates caching. Here is an
intro/overview to it...
http://www.learnasp.com/learn/rsfast-intro.asp
Here is the actual library ...
http://www.learnasp.com/learn/rsfast-lib.asp
I haven't used it, but it looks quite interesting - especially for us
Jet users.
- Jim
1) My ISP is www.brinkster.com and it supports MDB-database (and SQL
Server for some extra money)
2) Usually traffic comes from querying database: in case of .NET it is
possible to load entire database into disconnected recordsets, then
close MDB-database and feel good about any number of requests. Of
course, in case of update you still may open MDB, update and close but
that will not overload any system. Well, it is probably too late
advice for this particular app but next time you will know. Why to pay
for SQL if .Net provides disconnected recordsets?
See my site (disconnected from MDB): www.BuyFineArtOnline.com
Leo.
"cory" <no***@here.com> wrote in message news:<rkMKb.86812$6b2.26807@edtnps84>... Hi,
I have an Access database and am having an ASP.NEt application written for
it. It is almost complete. I have a hosting company that I signed up with
a month ago but before I did anything I asked them if Access and ASP.NET
would work on their servers, they said yes so I bought in. Now they are
saying my application wont work on their servers using MSaccess and I can
only use SQL or asp 3.0. They are saying Microsoft is trying to keep Ms
Access as a desktop application. The database is done, and the app is
almost done. I have paid alot of money for this application. What are my
options here?
How hard is it to convert an Access Database to SQL? What ramifications
does this have on the ASP.NET part?
How hard is it to convert to asp 3.0?
I was also told XML would work. DOnt know anything about it.
What about other hosts?
Any other options?
I just cant believe this.
Any help and insight would be greatly appreciated.
Cory This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Gary Dale |
last post by:
I have a database that was originally set up in Access 97 (because that
was what we had in the office). We had a copy of Access 2000 set up on
one machine for a brief period to get at another...
|
by: dixie |
last post by:
Can someone familiar with Access 2003 please answer this question? I am
asking because I don't have the use of A2003. When Access 2003 finds an
Access 2000 database, does it come up with some...
|
by: Dori |
last post by:
hi,
trying to convert access 97 to access 2003 with the access 2003
convertion tool of microsoft, but the only thing that isn't convert is
the modules in the vb of access 97.
what should i...
|
by: ET |
last post by:
I don't know whats the problem, but after I added functions
to first verify, then relink linked tables if not found,
now I can't convert that database to MDE format.
I can split the database, but...
|
by: Jon S via DotNetMonster.com |
last post by:
Hi all,
Is there a way to convert an Access.mdb from one format (say Access '97 or
Access 2000) to Access 2002 format using ADO.NET and C#??? I know how to do
it manually using the Access DBMS...
|
by: Bill Nicholson |
last post by:
What tools are available to convert Access projects (Forms, Code, Queries,
Reports) to VB Dot Net?
Does anyone have experience with this type of conversion? Please tell me I
don't have to do it...
|
by: Mamatha |
last post by:
Hi
I want to convert SQLServer database into MS-Access
through ASP program.Is there any possiblity to covert?If
possible please let me know and thanks in advance.
Mamatha
|
by: melickas |
last post by:
We designed a custom application using Office Developer Tools '97 which
included a Run-time version of Access--- so it would not matter if our
customer even had any version of Access on their...
|
by: tombsy |
last post by:
Hello Group.
I work for a company who is about to embark on a long awaited Office upgrade
from Office 97 to Office XP.
Office XP comes with Access 2002.
I am an accomplished Access developer...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
