473,326 Members | 2,048 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Is this feasible?

Hi

We have an access desktop app with front-end/back-end situation where all
tables are in the back end and everything else, forms/queries, are in the
front end. We would like to make a web app to use the same access database
but are worried about access being able to handle web app users. Is it
feasible to move the access backend tables to the SQL Server and link the
sql server tables in the access front end? It will not help access desktop
app as all processing will still be done by access but the web app can
presumably benefit from tables being on the SQL Server? Then over time we
can also re-write the access desktop app to be native sql.

Thanks

Regards

Nov 12 '05 #1
11 1730
Yes, yes, yes...

You are smart - that's good, thinking ahead seems to be overrated on this
subject, particularly in this group since there are some real mdb boneheads
around... :) (take it easy guys, just joking, kind of...)

Linking tables works fine, you will just have a little discomfort making
sure your datatypes are all in good shape. Also, if you rely on autonumbers
to relate tables, you will need to transfer those with IDENTITY INSERT
turned on within sql server, on whatever method you choose to move data with
(DTS, BCP, VB Code/ADO, etc, copy & paste using ADP).

I made a rule to never use mdb's as web database backends after countless
problems with file locking and other problems (both with syntax difference
and admins who think web folders should be read only), so you can probably
take it from there.

Good luck, I hope I gave you some good information - let me know how it
turns out for you? :)

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:3f**********************@news.dial.pipex.com. ..
Hi

We have an access desktop app with front-end/back-end situation where all
tables are in the back end and everything else, forms/queries, are in the
front end. We would like to make a web app to use the same access database
but are worried about access being able to handle web app users. Is it
feasible to move the access backend tables to the SQL Server and link the
sql server tables in the access front end? It will not help access desktop
app as all processing will still be done by access but the web app can
presumably benefit from tables being on the SQL Server? Then over time we
can also re-write the access desktop app to be native sql.

Thanks

Regards

Nov 12 '05 #2
Well, perhaps I am one of those "mdb boneheads" by Jerry's definition, but a
great deal of the success or failure of a Jet (not Access, please, Access
isn't running on the website) .MDB on a Web Site depends on how you try to
use it, and on the design of the accesses. There are a good many "server
snobs" around, too, who blame the tool for their own shortcomings. And,
while I'm not accusing Jerry of this, I am not joking one little bit about
it.

Jet wouldn't be a good engine for Amazon, but it is a perfectly useful and
usable engine for sites with "modest" usage. If the database and Jet are on
the same server as your .asp pages, and proper design/implementation, you
are likely to get better performance than you would with a comparable number
of concurrent users in a multiuser environment over a local network.

I'm not sure what you mean by "syntax difference" (different from _what_?).
And certainly, "admins who think web folders should be read only" is not a
problem that is related to a particular database, but to particular admins.
"Locking issues", absent other definition, sounds like it might be a
requirements/design/implementation problem that ought to be fixable with
some careful attention.

Now, all that said, this particular "MDB bonehead" has done most of his
paying work on Access clients to various server DB back ends, so has some
feel for both environments.

Larry Linson
Microsoft Access MVP
"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:t8********************@newssvr11.news.prodigy .com...
Yes, yes, yes...

You are smart - that's good, thinking ahead seems to be overrated on this
subject, particularly in this group since there are some real mdb boneheads around... :) (take it easy guys, just joking, kind of...)

Linking tables works fine, you will just have a little discomfort making
sure your datatypes are all in good shape. Also, if you rely on autonumbers to relate tables, you will need to transfer those with IDENTITY INSERT
turned on within sql server, on whatever method you choose to move data with (DTS, BCP, VB Code/ADO, etc, copy & paste using ADP).

I made a rule to never use mdb's as web database backends after countless
problems with file locking and other problems (both with syntax difference
and admins who think web folders should be read only), so you can probably
take it from there.

Good luck, I hope I gave you some good information - let me know how it
turns out for you? :)

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:3f**********************@news.dial.pipex.com. ..
Hi

We have an access desktop app with front-end/back-end situation where all tables are in the back end and everything else, forms/queries, are in the front end. We would like to make a web app to use the same access database but are worried about access being able to handle web app users. Is it
feasible to move the access backend tables to the SQL Server and link the sql server tables in the access front end? It will not help access desktop app as all processing will still be done by access but the web app can
presumably benefit from tables being on the SQL Server? Then over time we can also re-write the access desktop app to be native sql.

Thanks

Regards


Nov 12 '05 #3
i have heard access is good up to 10 hits per second

John Bickmore
www.BicycleCam.com
www.Feed-Zone.com

"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:3f**********************@news.dial.pipex.com. ..
Hi

We have an access desktop app with front-end/back-end situation where all
tables are in the back end and everything else, forms/queries, are in the
front end. We would like to make a web app to use the same access database
but are worried about access being able to handle web app users. Is it
feasible to move the access backend tables to the SQL Server and link the
sql server tables in the access front end? It will not help access desktop
app as all processing will still be done by access but the web app can
presumably benefit from tables being on the SQL Server? Then over time we
can also re-write the access desktop app to be native sql.

Thanks

Regards

Nov 12 '05 #4
"John" <Jo**@nospam.infovis.co.uk> wrote:
We have an access desktop app with front-end/back-end situation where all
tables are in the back end and everything else, forms/queries, are in the
front end. We would like to make a web app to use the same access database
but are worried about access being able to handle web app users. Is it
feasible to move the access backend tables to the SQL Server and link the
sql server tables in the access front end?
Sure is quite feasible.

Do a search at the Knowledge Base at support.microsoft.com using the keywords
"upsizing" to review the various white papers on upsizing Access to SQL Server as
well as to ensure you have any updates required.

Also see my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page at
my website.
It will not help access desktop
app as all processing will still be done by access
If you used views and stored procedures this would help performance somewhat. Mind
you Jet is remarkably efficient with moving stuff across the network.
but the web app can
presumably benefit from tables being on the SQL Server? Then over time we
can also re-write the access desktop app to be native sql.


Many queries will convert to views so long as you don't have too many oddball VBA
functions in queries. Although you may have to convert them yourself.

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 #5
Hope you weren't really offended by that Larry - so please don't take it
that way... you can call me a sql server bonehead if you want to, that's the
context I meant it in...

Have you had an affair with Sql Server yet? Or are you still 100% faithful
to Mrs. Jet? (hey, that rhymes)

I haven't seen any posts by your nemesis lately. I had a little psychic
encounter (you replied once in it) with him in pointing out that the group
wasn't the place for his demolition... from a neutral perspective - I hope
it contributed in some positive way. However, I do kind of miss the soap
opera type spatter you two generated. :) I always thought cdma was both
technically... and fun to read, almost addictive.

Now then... True - Jet is to blame, not Access. If you can show me how to
overcome this I will retract 80% of what I wrote and possibly start saying
nice things about .mdb's and web dev to the newbie's. To duplicate this
issue... run this asp code and use any .mdb database. Simply open the
database, then hit the page in whatever browser. Here is the type of
connection strings I use which are very standard...

cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\db6.mdb;Persist
Security Info=False"
or -- create a DSN and use...
cn.Open "myDSN"

-Begin Code---------------------------
<% 'test1.asp
dim cn
dim rs

set cn = Server.CreateObject("ADODB.Connection")

'cn.Open "DB6" 'in case we want to play with dsn props
cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\db6.mdb;Persist
Security Info=False"

Set rs = Server.CreateObject("ADODB.Recordset")
rs.CursorLocation = 1
rs.Open "SELECT anything from whatever'", cn, 1, 1

response.write "<table>"
do until rs.eof
response.write "<tr><td>" & rs.fields(0) & "</td></tr>"
rs.movenext
loop
response.write "</table>"
%>
-End Code---------------------------

-Begin Error-------------------------
--snip page cannot be displayed...
HTTP 500.100 - Internal Server Error - ASP error
Internet Information Services

----------------------------------------------------------------------------
----

Technical Information (for support personnel)

Error Type:
Microsoft JET Database Engine (0x80004005)
Could not use ''; file already in use.
/Malibu/test1.asp, line 7
Browser Type:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET
CLR 1.0.3705)

Page:
GET /test1.asp

Time:
Monday, December 29, 2003, 11:19:10 AM
-End Error---------------------------
Fyi, I do this all day long with SQL Server and ADP's, make/design
tables-sp's-views-functions, work data and security, tune indices, timer
driven sql agent jobs run, offsite synchronization occurs, DTS runs to
transform data from other sources, and none of this never interferes in any
noticeable way with the web pages, let alone that a lot of these features
are not even possible with .mdb's. I will never use mdb's again for the
web, but I might recommend them to newbie's with one or two simple tasks in
mind, which is why I still support them on my servers. I find that every
time someone starts a mdb database, they discover 50 new ideas that they
could be doing that just aren't possible with the mdb - like offsite data
maintenance with Access bound forms (doable with ADP's). It's at that point
that they realize that they should have started with Sql Server. It's like
building a house on sandy ground and then deciding to add a second story,
but realizing that you didn't extend the foundation to bedrock first. I
just feel that data is much less frustrating when it works regardless of the
situation you put it in and can grow/scale to any situation you can fathom.

In a light hearted way Larry, I have a hard time believing you have any
clients because I can't imagine you having time for them. You post so much
stuff that you must nearly call this a career on it's own. Kudos to you
sir, you have earned your flags like the others. I will never be able to
dedicate the time you do to this group. Just paying back what I take is all
I can do, without disappearing from my family life anyway. Take care, hope
you had a great xmas.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Larry Linson" <bo*****@localhost.not> wrote in message
news:KL******************@nwrddc01.gnilink.net...
Well, perhaps I am one of those "mdb boneheads" by Jerry's definition, but a great deal of the success or failure of a Jet (not Access, please, Access
isn't running on the website) .MDB on a Web Site depends on how you try to
use it, and on the design of the accesses. There are a good many "server
snobs" around, too, who blame the tool for their own shortcomings. And,
while I'm not accusing Jerry of this, I am not joking one little bit about
it.

Jet wouldn't be a good engine for Amazon, but it is a perfectly useful and
usable engine for sites with "modest" usage. If the database and Jet are on the same server as your .asp pages, and proper design/implementation, you
are likely to get better performance than you would with a comparable number of concurrent users in a multiuser environment over a local network.

I'm not sure what you mean by "syntax difference" (different from _what_?). And certainly, "admins who think web folders should be read only" is not a
problem that is related to a particular database, but to particular admins. "Locking issues", absent other definition, sounds like it might be a
requirements/design/implementation problem that ought to be fixable with
some careful attention.

Now, all that said, this particular "MDB bonehead" has done most of his
paying work on Access clients to various server DB back ends, so has some
feel for both environments.

Larry Linson
Microsoft Access MVP
"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:t8********************@newssvr11.news.prodigy .com...
Yes, yes, yes...

You are smart - that's good, thinking ahead seems to be overrated on this
subject, particularly in this group since there are some real mdb

boneheads
around... :) (take it easy guys, just joking, kind of...)

Linking tables works fine, you will just have a little discomfort making
sure your datatypes are all in good shape. Also, if you rely on

autonumbers
to relate tables, you will need to transfer those with IDENTITY INSERT
turned on within sql server, on whatever method you choose to move data

with
(DTS, BCP, VB Code/ADO, etc, copy & paste using ADP).

I made a rule to never use mdb's as web database backends after countless problems with file locking and other problems (both with syntax difference and admins who think web folders should be read only), so you can probably take it from there.

Good luck, I hope I gave you some good information - let me know how it
turns out for you? :)

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and Access
"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:3f**********************@news.dial.pipex.com. ..
Hi

We have an access desktop app with front-end/back-end situation where

all tables are in the back end and everything else, forms/queries, are in the front end. We would like to make a web app to use the same access database but are worried about access being able to handle web app users. Is it
feasible to move the access backend tables to the SQL Server and link the sql server tables in the access front end? It will not help access desktop app as all processing will still be done by access but the web app can
presumably benefit from tables being on the SQL Server? Then over time we can also re-write the access desktop app to be native sql.

Thanks

Regards



Nov 12 '05 #6
"Jerry Boone" wrote
Hope you weren't really offended by
that Larry - so please don't take it
that way...
I do get a little "out of sorts" when I see Access or Jet being "run down"
without good reason, but no personal offense taken.
Have you had an affair with Sql Server yet?
Or are you still 100% faithful
to Mrs. Jet? (hey, that rhymes)
AAMOF, toward the end of my previous post, I mentioned that _most_ of my
paying work has been Access clients to various server databases, and, yes,
some of those have been SQL Server databases. But, because of the clients'
corporate standard, most of it was against various versions of Informix.
Other apps, for other clients, used Sybase SQL Server and Sybase SQL
Anywhere.

I haven't done any web-based database applications, but have a number of
colleagues who have done so, both with Jet and with SQL Server databases.
They succeeded with both, but I hasten to point out that they are very
experienced and use a tool that is appropriate for the environment they are
addressing.
I haven't seen any posts by your nemesis
lately. I had a little psychic encounter (you
replied once in it) with him in pointing out
that the group wasn't the place for his
demolition... from a neutral perspective -
I hope it contributed in some positive way.
Unfortunately, he is immune to logic and reason. He is now posting
anonymously and using pseudonyms.
Now then... True - Jet is to blame, not
Access. If you can show me how to
overcome this I will . . .


As I said earlier, I haven't done any web-based database applications and
those are the only valid reason for using ADO. I have thought that for a
long time, and experienced Microsoft folk have just recently stated, that
MDB-Jet-ODBC-server is better than ADP-ADODB-Server, in all client-server
cases.

Thus, I would not be the one to try to "fix" serverside code that uses ADO.
I will say that looking at your code, it appears that you are simplying
trying to display one field of each record of a database table in an HTML
table. I have seen exactly that functionality demonstrated in more than one
application using .asp, vbscript, and ADO, so I know it can be successfully
done.

Larry Linson
Microsoft Access MVP


Nov 12 '05 #7
I have thought that for a
long time, and experienced Microsoft folk have just recently stated, that
MDB-Jet-ODBC-server is better than ADP-ADODB-Server, in all client-server
cases.


(sorry so long Larry, I didn't abbreviate much here because I wanted to give
you some real scenarios)

I can think of one right off that your favored method isn't better - and I
don't expect you to care since you probably don't need to use it this way.
Using Access remotely over an internet connection. I have seen people
scratch their heads on this topic and nobody has any real solutions for it
other than having it hosted on a Terminal Server. No thanks, too many
security issues here for the hostee.

So... it's better to me in these ways...

---------------------

1. Managed database services - Build a project and host the database.
Charge the customer for the delivered ade goods, then charge monthly for
hosting their data in a secure, web accessible style by giving them oledb
connection credentials from Sql Server. If they don't pay, back up the
database, burn it to disk, mail it, disable logins, done.

2. Web application data access - it's a showstopper... I give web app
customers one desktop icon to an ade with menu's and forms for updating
their web based data without telling them right away about what it does. I
can tell you right now that the most satisfaction I have ever had (besides
you know what) is when showing the database to the customer, adding some
data, having them ask "how do we get that to the web?" and just saying -
"just hit refresh, it's already there"... "wow, your kidding me!! Wow, this
is easy!!" - that isn't exaggerated one ounce... and is why I am successful
at what I do. I can build the adp FAST and it works great. Also, I have
never heard a single complaint about corruption, crashes, or the inability
to connect.

----------------------

You see, building bound mdb forms into the front end of a model that is
periodically "disconnected" over the "web" just doesn't appear viable with
mdb-jet-odbc (it just wasn't designed with this use in mind, dsn's are local
to the machine they exist on) unless you scrap the Jet-Odbc part and build
it using ADO and unbound forms where Jet is removed as the transport and ADO
recordsets are assigned to Access objects as recordsources. Andy B. and
Mary C. covered this pretty well in the book they did that covers
unbound/bound access mdb's and adp's. ADP's and SQL server are
significantly "better" here because of the very nature of the connection -
oledb.

I can host SQL Server databases from my database servers and as long as port
1433 (or whatever port I choose to host sql on) is open, ADP's can access
the data and work over any Internet connection (yes, I even found dial up is
not bad if you keep what you display to a reasonable amount) just as if they
were sitting next to the server, using bound object methodology. In my
world, I can build an ADP, release it to my customer, and charge for the
application and monthly managed database services.

We all sacrifice speed for the amount of code/features we execute/demand.
In that technical aspect, flat binary files would be even "better". But I
don't need to argue with you about it - I saw what you did to Kaplan when he
was trying to get you to look at .net... I think he nearly had an
aneurism... unfortunately I believe I would suffer the same fate convincing
you that adp's and sql server are better... or a php developer telling me
that .net is not better... so the differences remain, oh well [sigh].

In all, I feel that programming and databases are just tools that can
consume thousands of hours in training to become truly proficient. I have
made 4 transitions in products over the last 7 years and it's really tiring
as you more than likely know. I always thought plumbing would be good, the
biggest change they made in 50 years was cast iron to plastic...

The ADO code I threw in was merely a very stripped down way to hit Jet for
some data and loop it onto the page. There is absolutely nothing wrong with
the code. I have used ADO literally inside-out to work with data, the suite
of components are vital in my daily operations. I understand that you are
not up to this question, but thanks for checking it out.

I appreciate your time and dedication sir.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
Nov 12 '05 #8
Thanks Chuck,

I do understand that the directory has to have write perms and that IIS uses
such credentials - that I am crystal clear on, but is not the problem in
this case.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Chuck Grimsby" <c.*******@worldnet.att.net.invalid> wrote in message
news:eg********************************@4ax.com...

Check and make sure that the account that is specified in the
website's anonymous user has write permissions to the directory that
the mdb resides in. (The "anonymous user account" is badly named. It
should be called the "User Account To Impersonate" in my mind, since
it's the "user" the website will impersonate when doing *everything*.)

Nov 12 '05 #9
Jerry,

Yours is the first, at least the first _credible_, account that I have seen
of actually using an ADP across the Internet. Having that rich-client work
with a miserably slow connection (as any Internet connection tends to be,
and dial-up IN SPADES) is indeed an advantage. So, I am going to have to see
what I can do about taking advantage of your pioneering experience -- I may
have to talk some colleagues into installing some things on a development
server, so I can test over a real internet connection.

It wasn't I who did the testing and offered the "revised" opinion on ADP vs
MDB, but some very knowledgeable and experienced folks within Microsoft (I
am not at liberty to say who it is). Perhaps they were just talking about
the "standard straight client-server on a LAN/WAN".

In re: dot NET. As I have said all along, "for me, the saving grace may be
that ASP.NET will make it simple(r) to create simple, modest web-based
database applications". Now that the second version has been released, and
we have seen some "peeks ahead" into the next version, it appears to me that
..NET is beginning to stabilize to the extent that they can do some work on
the UI to make it easier and more usable for smaller users' applications,
instead of _just_ worrying about making the whole "enterprise distributed
app" thing work, which is my view of what's been going on up to now..

Thus, I am beginning to take a closer look at ASP.NET, at the Visual Studio
environment, at Web Matrix, and at ADO.NET for accessing databases. In fact,
as the special interest groups in my user group have matured and evolved, I
am now an Assistant SIG Leader for the ASP.NET SIG. How's _that_ for a
change in (apparent) position?

Larry Linson
Microsoft Access MVP

"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:Yu****************@newssvr24.news.prodigy.com ...
I have thought that for a
long time, and experienced Microsoft folk have just recently stated, that MDB-Jet-ODBC-server is better than ADP-ADODB-Server, in all client-server cases.
(sorry so long Larry, I didn't abbreviate much here because I wanted to

give you some real scenarios)

I can think of one right off that your favored method isn't better - and I
don't expect you to care since you probably don't need to use it this way.
Using Access remotely over an internet connection. I have seen people
scratch their heads on this topic and nobody has any real solutions for it
other than having it hosted on a Terminal Server. No thanks, too many
security issues here for the hostee.

So... it's better to me in these ways...

---------------------

1. Managed database services - Build a project and host the database.
Charge the customer for the delivered ade goods, then charge monthly for
hosting their data in a secure, web accessible style by giving them oledb
connection credentials from Sql Server. If they don't pay, back up the
database, burn it to disk, mail it, disable logins, done.

2. Web application data access - it's a showstopper... I give web app
customers one desktop icon to an ade with menu's and forms for updating
their web based data without telling them right away about what it does. I can tell you right now that the most satisfaction I have ever had (besides
you know what) is when showing the database to the customer, adding some
data, having them ask "how do we get that to the web?" and just saying -
"just hit refresh, it's already there"... "wow, your kidding me!! Wow, this is easy!!" - that isn't exaggerated one ounce... and is why I am successful at what I do. I can build the adp FAST and it works great. Also, I have
never heard a single complaint about corruption, crashes, or the inability
to connect.

----------------------

You see, building bound mdb forms into the front end of a model that is
periodically "disconnected" over the "web" just doesn't appear viable with
mdb-jet-odbc (it just wasn't designed with this use in mind, dsn's are local to the machine they exist on) unless you scrap the Jet-Odbc part and build
it using ADO and unbound forms where Jet is removed as the transport and ADO recordsets are assigned to Access objects as recordsources. Andy B. and
Mary C. covered this pretty well in the book they did that covers
unbound/bound access mdb's and adp's. ADP's and SQL server are
significantly "better" here because of the very nature of the connection -
oledb.

I can host SQL Server databases from my database servers and as long as port 1433 (or whatever port I choose to host sql on) is open, ADP's can access
the data and work over any Internet connection (yes, I even found dial up is not bad if you keep what you display to a reasonable amount) just as if they were sitting next to the server, using bound object methodology. In my
world, I can build an ADP, release it to my customer, and charge for the
application and monthly managed database services.

We all sacrifice speed for the amount of code/features we execute/demand.
In that technical aspect, flat binary files would be even "better". But I
don't need to argue with you about it - I saw what you did to Kaplan when he was trying to get you to look at .net... I think he nearly had an
aneurism... unfortunately I believe I would suffer the same fate convincing you that adp's and sql server are better... or a php developer telling me
that .net is not better... so the differences remain, oh well [sigh].

In all, I feel that programming and databases are just tools that can
consume thousands of hours in training to become truly proficient. I have
made 4 transitions in products over the last 7 years and it's really tiring as you more than likely know. I always thought plumbing would be good, the biggest change they made in 50 years was cast iron to plastic...

The ADO code I threw in was merely a very stripped down way to hit Jet for
some data and loop it onto the page. There is absolutely nothing wrong with the code. I have used ADO literally inside-out to work with data, the suite of components are vital in my daily operations. I understand that you are
not up to this question, but thanks for checking it out.

I appreciate your time and dedication sir.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

Nov 12 '05 #10
Yes - server.mappath is great, I use it all of the time in many ways. I
used a direct path here to simplify the example.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Chuck Grimsby" <c.*******@worldnet.att.net.invalid> wrote in message
news:f6********************************@4ax.com...

The connection string you posted is a bit different from what I
usually use. I (intensely) dislike using "fixed" locations for the
database. Strange as it may seem, I run into an awful lot of cases
where the client moves the website around (for whatever reason) and
thus database. So rather then using "c:\db6.mdb", I'll use the
Server.MapPath() function to get the location of the database, usually
bound to a variable so I can see what it is when I need to.

Dim myDB, strConn
myDB = Server.MapPath("db6.mdb")
' Response.Write myDB
strConn = "Provider=Microsoft.Jet.OLEDB.4.0;"
strconn = strConn & "Data Source=" & mydb
strConn = strConn & ";Persist Security Info=False"

cn.Open strConn

I've also used:

"DBQ=" & myDB & ";Driver={Microsoft Access Driver (*.mdb)};"

as the connection string. Sometimes one works, sometimes the other.
I don't worry about why....
On Tue, 30 Dec 2003 16:24:58 GMT, "Jerry Boone"
<je***@antech.biz.killspam> wrote:
I do understand that the directory has to have write perms and that IIS usessuch credentials - that I am crystal clear on, but is not the problem in
this case.

"Chuck Grimsby" <c.*******@worldnet.att.net.invalid> wrote in message
news:eg********************************@4ax.com.. .
Check and make sure that the account that is specified in the
website's anonymous user has write permissions to the directory that
the mdb resides in. (The "anonymous user account" is badly named. It
should be called the "User Account To Impersonate" in my mind, since
it's the "user" the website will impersonate when doing *everything*.)

--
Just Remember: Today Is The First Day After Yesterday.

Nov 12 '05 #11
Good, better, great!

You know, it only took me 2 years to find something on ADP's that you would
find "credible". There are others, however you will have to find those out
on your own...

If you are serious about doing some ADP testing, I would be glad to setup a
database and login for you - no problem, let me know and it's done. All I
ask is for an honest recommendation of my services to others if you find it
useful.

ASP.Net is a bombshell - but to be all around great, you really need either
a graphics person or to be adept in that profession. I think it's far more
technically in-depth than working with ADP's because you now have so many
more factors in place like IIS, enormous class libraries, third party
components to get showstopper features, and the most comprehensive IDE in
history. If you work with it everyday, you might start remembering what
things are and how to use them in about 6 months. Still, the downside of
the IDE is that while it promises to release a version that does... it will
not allow you to break-edit-continue, which is very mundane after being used
to debugging in vb/vba.

That said, if you just want to deliver some small apps and utilize your
Access background, then you can see that adp's are clearly meaningful.

I found some really great online conferences covering .net from the
Microsoft PDC 2003. A huge amount of sessions covering .net are available
for free - spoken in English by pro's with slides and screen action, and no
airline tickets involved :)

http://microsoft.sitestream.com/PDC2003/Default.htm

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Larry Linson" <bo*****@localhost.not> wrote in message
news:WF*******************@nwrddc02.gnilink.net...
Jerry,

Yours is the first, at least the first _credible_, account that I have seen of actually using an ADP across the Internet. Having that rich-client work
with a miserably slow connection (as any Internet connection tends to be,
and dial-up IN SPADES) is indeed an advantage. So, I am going to have to see what I can do about taking advantage of your pioneering experience -- I may have to talk some colleagues into installing some things on a development
server, so I can test over a real internet connection.

It wasn't I who did the testing and offered the "revised" opinion on ADP vs MDB, but some very knowledgeable and experienced folks within Microsoft (I
am not at liberty to say who it is). Perhaps they were just talking about
the "standard straight client-server on a LAN/WAN".

In re: dot NET. As I have said all along, "for me, the saving grace may be
that ASP.NET will make it simple(r) to create simple, modest web-based
database applications". Now that the second version has been released, and
we have seen some "peeks ahead" into the next version, it appears to me that .NET is beginning to stabilize to the extent that they can do some work on
the UI to make it easier and more usable for smaller users' applications,
instead of _just_ worrying about making the whole "enterprise distributed
app" thing work, which is my view of what's been going on up to now..

Thus, I am beginning to take a closer look at ASP.NET, at the Visual Studio environment, at Web Matrix, and at ADO.NET for accessing databases. In fact, as the special interest groups in my user group have matured and evolved, I am now an Assistant SIG Leader for the ASP.NET SIG. How's _that_ for a
change in (apparent) position?

Larry Linson
Microsoft Access MVP

"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:Yu****************@newssvr24.news.prodigy.com ...
I have thought that for a
long time, and experienced Microsoft folk have just recently stated, that MDB-Jet-ODBC-server is better than ADP-ADODB-Server, in all client-server cases.
(sorry so long Larry, I didn't abbreviate much here because I wanted to

give
you some real scenarios)

I can think of one right off that your favored method isn't better - and I don't expect you to care since you probably don't need to use it this way. Using Access remotely over an internet connection. I have seen people
scratch their heads on this topic and nobody has any real solutions for it other than having it hosted on a Terminal Server. No thanks, too many
security issues here for the hostee.

So... it's better to me in these ways...

---------------------

1. Managed database services - Build a project and host the database.
Charge the customer for the delivered ade goods, then charge monthly for
hosting their data in a secure, web accessible style by giving them oledb connection credentials from Sql Server. If they don't pay, back up the
database, burn it to disk, mail it, disable logins, done.

2. Web application data access - it's a showstopper... I give web app
customers one desktop icon to an ade with menu's and forms for updating
their web based data without telling them right away about what it does.

I
can tell you right now that the most satisfaction I have ever had (besides you know what) is when showing the database to the customer, adding some
data, having them ask "how do we get that to the web?" and just saying -
"just hit refresh, it's already there"... "wow, your kidding me!! Wow,

this
is easy!!" - that isn't exaggerated one ounce... and is why I am

successful
at what I do. I can build the adp FAST and it works great. Also, I have never heard a single complaint about corruption, crashes, or the inability to connect.

----------------------

You see, building bound mdb forms into the front end of a model that is
periodically "disconnected" over the "web" just doesn't appear viable with mdb-jet-odbc (it just wasn't designed with this use in mind, dsn's are

local
to the machine they exist on) unless you scrap the Jet-Odbc part and build it using ADO and unbound forms where Jet is removed as the transport and

ADO
recordsets are assigned to Access objects as recordsources. Andy B. and
Mary C. covered this pretty well in the book they did that covers
unbound/bound access mdb's and adp's. ADP's and SQL server are
significantly "better" here because of the very nature of the connection - oledb.

I can host SQL Server databases from my database servers and as long as

port
1433 (or whatever port I choose to host sql on) is open, ADP's can access the data and work over any Internet connection (yes, I even found dial up is
not bad if you keep what you display to a reasonable amount) just as if they
were sitting next to the server, using bound object methodology. In my
world, I can build an ADP, release it to my customer, and charge for the
application and monthly managed database services.

We all sacrifice speed for the amount of code/features we

execute/demand. In that technical aspect, flat binary files would be even "better". But I don't need to argue with you about it - I saw what you did to Kaplan when he
was trying to get you to look at .net... I think he nearly had an
aneurism... unfortunately I believe I would suffer the same fate

convincing
you that adp's and sql server are better... or a php developer telling

me that .net is not better... so the differences remain, oh well [sigh].

In all, I feel that programming and databases are just tools that can
consume thousands of hours in training to become truly proficient. I have made 4 transitions in products over the last 7 years and it's really

tiring
as you more than likely know. I always thought plumbing would be good,

the
biggest change they made in 50 years was cast iron to plastic...

The ADO code I threw in was merely a very stripped down way to hit Jet for some data and loop it onto the page. There is absolutely nothing wrong

with
the code. I have used ADO literally inside-out to work with data, the

suite
of components are vital in my daily operations. I understand that you are not up to this question, but thanks for checking it out.

I appreciate your time and dedication sir.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and Access


Nov 12 '05 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Jake | last post by:
I apologize for what is probably a "stupid", uninformed question but here goes... I just inherited an ASP site project currently running off of a Microsoft Access DB which I'd really like to...
2
by: justin allen | last post by:
I'm wondering if there would be a way to do such a thing as overloading the () operator of a class in order to use that class as a callback function. I presently would love to do this with the...
0
by: Richard Blewett [DevelopMentor] | last post by:
The problem with trying to use CAS to do this on a machine that you don't control is that anyone with admin privilege on the machine can run caspol -i off and all your carefully crafted...
4
by: lcazarre | last post by:
I am by no means a serious programmer (which will become evident as you read this very message), except that I use VBA almost daily to automate Excel spreadsheets. I do enjoy programming however...
6
by: Osiris | last post by:
Is the following intuitively feasible in Python: I have an array (I come from C) of identical objects, called sections. These sections have some feature, say a length, measured in mm, which is...
0
by: createdefuture | last post by:
chech wat is happening here.. http://www.createthefuturecontest.com/pages/view/entriesdetail.html?entryID=798
1
by: createurfuture | last post by:
pls chk this and comment on the design. http://createthefuturecontest.com/pages/view/entriesdetail.html?entryID=798
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.