Can it be that NO ONE HERE knows this answer?
Lauren Wilson
After ransacking the Desktop AND Enterprise edition of Ken Getz Dev
Handbooks on Access 2002, I STILL don't know if it is or is not
possible to link a client side MDE with a WEB server MDB table using
ADO.
Does ANYONE know the correct answer to that question?
John Mishefske
No. There may be technologies available to handle the TCP/IP communication
between a client and server but its not built-in to Access.
One such technology:
http://www.unix.org.ua/orelly/linux/dbi/ch08_02.htm
--
'---------------
'John Mishefske
'---------------
planetthoughtful
itself?
One possible solution would be to write a transaction handling page on
your web server, so that your client side MDE interrogates the page,
which in turn interrogates your web server MDB. It's a little kludgy,
but I've seen it used in other apps.
Do a Google search on "Microsoft.XMLHTTP" if this is a path you'd like
to pursue further, and here's a link to an older thread in this
newsgroup that covers a similar topic.
Much warmth,
planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org
rkc
You can send requests to a web server using VBA and methods of
Microsoft.XMLHTTP which is part of the Microsoft.MSXML library.
There are examples to be found using Google, but since it is
technology meant to be used via a web browser the examples are
mostly in ASP. Perl, PHP, etc.
You don't talk directly to the .mdb file. You send requests or
Post data to 'web pages' that communicate with the .mdb file via
the scripting language of your choice.
Lyle Fairfield
I do know that I have never done it and that I know of no example if
its being done and that I know of no instructions on how to do it.
It is my opinion that you often decide on solutions by yourself and
then seek in CDMA the "how to" of the solution without discussion of
the problem and which solution might be appropriate. It is also my
opinion that this strategy sometimes leads you to accept and to note
your support for ideas, strategies and code which are suspect, if not
down-right nonsense.
Lauren Wilson
<lylefa...@aim.com> wrote:
>I don't know the correct answer.
>I do know that I have never done it and that I know of no example if
>its being done and that I know of no instructions on how to do it.
>It is my opinion that you often decide on solutions by yourself and
>then seek in CDMA the "how to" of the solution without discussion of
>the problem and which solution might be appropriate.
Interesting -- my posting pattern has drawn your attention!
I don't know whether to be concerned or pleased.
You are correct that I often decide on the solution and then seek
advice on how to implement it. If I fail to post complete context, it
is due to time restrictions and, to some degree, non-disclosure
agreements and other legal obligations to which I am a party. My
personal inclination is to include MORE detail than needed to address
the problem. People often accuse me of telling them how to build a
clock, when the time of day was all they wanted to know.
>It is also my opinion that this strategy sometimes leads you to accept and to note
>your support for ideas, strategies and code which are suspect, if not down-right nonsense.
I assure you, I have never IMPLEMENTED nonsense coding advice. If I
have appeared to approve of or recommend nonsense, then thanks for
your insight and effort. Would you be so kind as to describe an
example from this group where I have demonstrated such behavior?
If you succeed, I will GLADLY admit it and thank you publicly for
identifying my error.
In any case, I'm not a big fan of re-inventing the wheel. If I can
get a quick answer here from kind folks who do me the honor of
sharing, why should I (or anyone) waste time doing original research
on issues that thousands of others have already competently done?
Is that not one of the intended results of this group?
I believe this group is a significant force for good in support of the
human economic engine -- and YOUR contributions are much appreciated.
David W. Fenton
news:sduh12dk657lp6mkg...@4ax.com:
You're asking if Access can retrieve data over HTTP with ADO?
The answer is NO.
But there are ways to get HTML data into Access retrieved over HTTP,
but it doesn't involve ADO between the local and remote Access
databases.
Access 12 may actually change this. I note in yesterday's Access 12
blog entry and example of linking to a schema on a SharePoint
server, and it uses HTTP as its protocol for defining the remote
server, which suggests that Access 12 communicates with SharePoint
Server via HTTP.
I don't know if that helps or confuses things!
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
rkc
Your down right contempt for 90% of the people that post here is
becoming more apparent every day. Must be a burden that accompanies
a genius IQ.
Jerry Boone
accomplish would certainly help...
Sounds like you want MDE code (which I presume you control the source code
of, otherwise you may want to forget it) to insert/update/delete an MDB
stored in a web folder on your website?
If that is true, then the only way I could see you making progress is by
building a web service in .net with 3 methods (insert/update/delete). You
then would need to build a .net client side application to talk to the web
service (or locate some kind of com based webservice dll) to have your mde
code talk to. This would simply be a translator, working over port 80 in a
very savvy way. It basically automates all the xml document
creation/transmission/consumption (and vice versa) for you. Once this is
all in place, theoretically your in business.
Of course there are probably other ways to do this, it's one way I know of -
others may provide them or they may not.
If you were willing to talk to something other than an MDB then I would
probably put Sql server to work on the web server, open up port 1433 to a
fixed client IP with tight security credentials and talk to sql directly
with ADO - easy solution.
--
Jerry Boone
"Lauren Wilson" <nos...@nospam.com> wrote in message
news:sduh12dk657lp6mkg...@4ax.com...
david epsom dot com dot au
"You cannot import or link a Microsoft Access database or an ODBC data
source on an FTP or HTTP server."
(david)
"Lauren Wilson" <nos...@nospam.com> wrote in message
news:sduh12dk657lp6mkg...@4ax.com...
Lauren Wilson
Oh it DEFINITELY helps! Thanks David. You are SUCH a good guy!
This is the kind of answer I was looking for -- high level view of the
issue.
Now, what about that blog you mentioned above. Can we have a link?
Lyle Fairfield
> Your down right contempt for 90% of the people that post here is
> becoming more apparent every day.
Should I run for President?
Terry Kreft
Get a Fair Deal with Fairfield for President
I think it will get the intellectual voter myself.
--
Terry Kreft
"Lyle Fairfield" <lylefa...@aim.com> wrote in message
news:1142613543.2...@i40g2000cwc.googlegroups.com...
Lyle Fairfield
Access CAN retrieve data over HTTP with ADO.
Try this:
Sub temp()
Dim r As ADODB.Recordset
Set r = New ADODB.Recordset
With r
.CursorLocation = adUseClient
.CursorType = adOpenKeyset
.LockType = adLockBatchOptimistic
.Open "http://ffdba.com/ffdbaAccounts.xml"
While Not .EOF
Debug.Print Trim(.Fields(1).Value)
.MoveNext
Wend
End With
End Sub
Is it data?
Did it come "over" http?
Was it "with" ADO?
Could we write something to modify or add to this to this data and save
our updates? Yes, we could.
Rick Brandt
<nit>
But the OP did specify data from an MDB file.
<pick>
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Lyle Fairfield
rkc
I thought Canada had a Queen.
David W. Fenton
> Now, what about that blog you mentioned above. Can we have a
> link?
I would think everyone interested in the future of Access should be
reading it.
Lauren Wilson
Interesting. If this works, it's exactly what I had in mind. However,
SOME people in this group are claiming this is not possible.
Hmmmm. Oh darn! Guess I'll have to just try it.
Thanks Lyle
-- LW
On 17 Mar 2006 09:49:08 -0800, "Lyle Fairfield"
Lauren Wilson
True, however, I see no reason why we could not use XML.
Lauren Wilson
<lylefa...@aim.com> wrote:
Lyle, have you actually used the code you posted and succeeded in
reading and writing data to/from an MDB file on a web server?
Lauren Wilson
Is this true of Access 2003?
Lyle Fairfield
there.
Writing Data will take a little longer. Maybe tomorrow.
David W. Fenton
> Interesting. If this works, it's exactly what I had in mind.
> However, SOME people in this group are claiming this is not
> possible. Hmmmm. Oh darn! Guess I'll have to just try it.
What Lyle is suggesting requires some intermediate tech between the
MDB and the ADO connection to create the XML stream. You asked about
ADO -> MDB, but Lyle is giving you a different answer.
It's basically no different than the XHTML answers others gave,
since it requires a server-side component to produce the XML.
David W. Fenton
What is running on the server to produce the XML? That's the part
Lyle has left out of the equation.
His answer leaves out the "from an MDB" part that is so crucial to
your original question.
Lyle Fairfield
> I can think of no reason you can't run the ""exact"" code. The file is
> there.
>
> Writing Data will take a little longer. Maybe tomorrow.
We can write the data to a local file and upload it all with ADO only.
Sub RecordsetOnHttp()
Dim r As ADODB.Recordset
Set r = New ADODB.Recordset
With r
.Open "http://ffdba.com/ffdbaAccounts.xml", , adOpenKeyset,
adLockBatchOptimistic
While Not .EOF
Debug.Print .Collect(1)
.MoveNext
Wend
.AddNew Array(1, 2, 3), Array(Format(Now, "yyyymmddhhnnss"), Null,
False)
If DoesFileExist1997("ffdbaAccounts.xml") Then Kill
"ffdbaAccounts.xml"
.Save "ffdbaAccounts.xml", adPersistXML
End With
UploadFile "ffdbaAccounts.xml", "ffdbaAccounts.xml", "http://ffdba.com",
"UserName", "PassWord"
End Sub
Public Sub UploadFile( _
ByVal FromPath As String, _
ByVal ToFile As String, _
ByVal Server As String, _
Optional ByVal UserName As String, _
Optional ByVal PassWord As String)
Dim r As ADODB.Record
Dim s As ADODB.Stream
Set r = New ADODB.Record
Set s = New ADODB.Stream
r.Open Server & "/" & ToFile, , adModeWrite, adCreateOverwrite, ,
UserName, PassWord
With s
.Open r, , adOpenStreamFromRecord
.Type = adTypeBinary
.LoadFromFile FromPath
.Close
End With
r.Close
End Sub
Public Function DoesFileExist1997(ByVal FilePath As String) As Boolean
Const FileNotFoundErrNumber As Long = 53
On Error GoTo DoesFileExist1997Err
GetAttr FilePath
DoesFileExist1997 = True
DoesFileExist1997Exit:
Exit Function
DoesFileExist1997Err:
With Err
If .Number <> FileNotFoundErrNumber Then
MsgBox .Description, vbCritical, "Error Number: " & .Number
End If
End With
Resume DoesFileExist1997Exit
End Function
I have added 3 records to the Recordset. It is quite interesting to see
how these are saved in the xml.
<snips>
<z:row AccountID='19' CommonName='Income Tax' FormalDescription=''/>
<z:row AccountID='20' CommonName='Terraware' FormalDescription=''
IncludeInSummary='True'/>
<z:row AccountID='21' CommonName='Temp'
FormalDescription='Temporary' IncludeInSummary='True'/>
<rs:insert>
<z:row CommonName='NewName' IncludeInSummary='False'
rs:forcenull='FormalDescription'/>
<z:row CommonName='20060317211431' IncludeInSummary='False'
rs:forcenull='FormalDescription'/>
<z:row CommonName='20060317211440' IncludeInSummary='False'
rs:forcenull='FormalDescription'/>
</rs:insert>
They are saved as inserts. If we (ever) retach this recordset to its
parent database and updatebatch it, these new records will be saved.
I do not know if my upload is redundant because the save could be made
directly to the http server.
I do not know if my file upload will work on a non-ms server.
But I do know that data can be accessed from, modified, added to, and
saved to an http server using only ADO. I have done it. The code is there
for you to see.
Yes, I know this is strictly flat file. Yes I know it’s not an mdb. Yes I
know that there is no simultaneous user safeguard whatever. BUT IT IS
DATA, IT IS ACCESSED WITH ADO, AND IT IS THROUGH HTTP.
Could I use and edit the recordset with a form? Sure, I could.
--
Lyle Fairfield
Lauren Wilson
They have quite a few "queens". Ever been to Montreal or Vancouver?
Lauren Wilson
<XXXu...@dfenton.com.invalid> wrote:
>Lauren Wilson <nos...@nospam.com> wrote in
>news:a48m125erv645fudf...@4ax.com:
>
>> Interesting. If this works, it's exactly what I had in mind.
>> However, SOME people in this group are claiming this is not
>> possible. Hmmmm. Oh darn! Guess I'll have to just try it.
>
>What Lyle is suggesting requires some intermediate tech between the
>MDB and the ADO connection to create the XML stream. You asked about
>ADO -> MDB, but Lyle is giving you a different answer.
>
>It's basically no different than the XHTML answers others gave,
>since it requires a server-side component to produce the XML.
I understand. However, I'm not sure why we couldn't just use XML all
the way.
Lauren Wilson
this appears to be what we need. Thanks a lot Lyle. I'm believe we
can adapt this approach to our needs. The amount of data we require
for this project component is VERY small -- maybe 3-4 fields per user.
Each user can have their own XML file with a name equal to their user
account number.
Lauren Wilson
<XXXu...@dfenton.com.invalid> wrote:
>Lauren Wilson <nos...@nospam.com> wrote in
>news:u98m129vv49ql8emg...@4ax.com:
>
>> On 17 Mar 2006 11:29:44 -0800, "Lyle Fairfield"
>><lylefa...@aim.com> wrote:
>>
>>>The quote ti which I referred is:
>>>
>>>"You're asking if Access can retrieve data over HTTP with ADO?
>>>
>>>The answer is NO."
>>
>> Lyle, have you actually used the code you posted and succeeded in
>> reading and writing data to/from an MDB file on a web server?
>
>What is running on the server to produce the XML? That's the part
>Lyle has left out of the equation.
I believe, in this case, all the XML can be generated on the client
end and simply stored on the server for future
retrieve/read/write/replace operations using code similar to what Lyle
posted.
Thanks for your counterpoint views.
>
>His answer leaves out the "from an MDB" part that is so crucial to
>your original question.
Lyle's willingness to think outside the box that I created has
revealed a possible solution that I had not yet considered. That
shift in perspective may result in a better solution than I originally
had in mind.
Lyle Fairfield
@twister.nyroc.rr.com:
That's for 99.44 % contemptibles.
--
Lyle Fairfield
Lyle Fairfield
Hmmm ... I think this might be interpreted to be a statement about sexual
preference. It is not. It is a statement about government preference.
--
Lyle Fairfield
rkc
Oh yeah, be careful. Wouldn't want to offend anything less than an
entire country.
Lyle Fairfield
news:f5TSf.9766$Da7....@twister.nyroc.rr.com:
> Oh yeah, be careful. Wouldn't want to offend anything less than an
> entire country.
I thought it would only be around 40%?
http://www.pollingreport.com/BushJob.htm
--
Lyle Fairfield
David W. Fenton
You mean skip the MDB and store the data in XML files?
Well, here are some reasons:
1. loss of referential integrity.
2. loss of validity checking of data types.
3. loss of indexes to improve searching performance.
4. verbosity of storage -- much greater than in a binary format like
an MDB.
XML seems to me to make sense only as a data interchange format. For
really working with large amounts of data, an actual database is
necessary. If you've ever programmed a database-like application
against plain text files, you'll know what the problems. Yes, ADO
provides a db-like interface to XML files, but that's only on the
surface.
It would mean putting everything the database engine does for you
into the application, and that's bad, in my opinion.
In the situation you describe, if I were considering abandoning the
MDB, I think I'd go with a server back end and connect to that
across the Internet (preferably on a VPN connection, if that's
possible), rather than completely abandoning a proper database
store.
David W. Fenton
> On Fri, 17 Mar 2006 15:41:57 -0600, "David W. Fenton"
><XXXu...@dfenton.com.invalid> wrote:
>
>>Lauren Wilson <nos...@nospam.com> wrote in
>>news:u98m129vv49ql8emg...@4ax.com:
>>
>>> On 17 Mar 2006 11:29:44 -0800, "Lyle Fairfield"
>>><lylefa...@aim.com> wrote:
>>>
>>>>The quote ti which I referred is:
>>>>
>>>>"You're asking if Access can retrieve data over HTTP with ADO?
>>>>
>>>>The answer is NO."
>>>
>>> Lyle, have you actually used the code you posted and succeeded
>>> in reading and writing data to/from an MDB file on a web server?
>>
>>What is running on the server to produce the XML? That's the part
>>Lyle has left out of the equation.
>
> I believe, in this case, all the XML can be generated on the
> client end and simply stored on the server for future
> retrieve/read/write/replace operations using code similar to what
> Lyle posted.
>
> Thanks for your counterpoint views.
I assume you own't mind, then, if I continue to dissent? :)
>>His answer leaves out the "from an MDB" part that is so crucial to
>>your original question.
>
> Lyle's willingness to think outside the box that I created has
> revealed a possible solution that I had not yet considered. That
> shift in perspective may result in a better solution than I
> originally had in mind.
I think this is a terrible idea, myself. You're basically going to
re-implement replication with text files, and this is horrendously
difficult. You're also giving up all the benefits of having a db
engine.
Is running SQL Server or some other server db on the web server not
a possibility?
Lyle Fairfield
preferable if there is some actual work to be done. A good one can be
rented for $20 (US) per month, probably cheaper if one looks around, as
that price includes a web site.
But if one is only checking a version number, or date, XML would
suffice.
I would go the $20 site / MS-SQL db route myself and get the db and all
its power; I'd put documentation on the site in html files, have a mail
to developer page there too (like yours) and create an introductory
Power Point Application.
But that's just my personal preference.
Lauren Wilson
<XXXu...@dfenton.com.invalid> wrote:
It is. I would rather do it with SQL Server, or MySQL. It appears
that a DAP can connect to a remote SQL Server database. If so,
believe (hope) I can create a hidden DAP form to be the interface for
this licensing, update checking process. I know, I know. DAPs are
going away in Office 12. But we should be able to continue using
Access 2003 for at least another 2-3 years. After that, I'll just
re-write the procedure using the Access 12 technology. Since it's a
process that's transparent to the user, they'll never know the
difference.
Lyle Fairfield
DAPs are for editing, appending and deleting data. Hiding a DAP is
basically inconsistent with its reason for being.
DAPs can be visible or not visible.
But the DAP object can be hidden or not hidden. When it's hidden its
attributes are ored with 8. I don't know of a way to un-or them (not
eight) as they are read-only except in the ui and when the page is
hidden the ui can't find it , that is to show the object once its been
hidden. (Perhaps, someone will enlighten me.)
DAPs are, for the most part, external .htm files. These files must
contain the connection information (to the db the DAO uses), or the
user must log on. If you want these to be secret then you won't,I
think, want the user to logon. If the connection data is in the htm
file then your data security may be compromised. ANyone who opens the
htm file in notepad can read it.
If you hide the file, hide the object and make the DAP not visible then
you will have three states of visibility to manage with code, secretly.
I think this might be an opportunity for the pain of "I didn't think of
that".
What could you do with a hidden DAP that you couldn't do with a simple
OleDB-ADO connection to your MS-SQL db and recordset in a VBA Module,
encrypting your logon etc?
.
rkc
> One more try.
>
> After ransacking the Desktop AND Enterprise edition of Ken Getz Dev
> Handbooks on Access 2002, I STILL don't know if it is or is not
> possible to link a client side MDE with a WEB server MDB table using
> ADO.
>
> Does ANYONE know the correct answer to that question?
One more try.
<PhoneHome>
Sub PhoneHome()
Dim msXML As Object
Set msXML = CreateObject("Microsoft.XMLHTTP")
With msXML
'.Open "POST", "http://localhost/RegCheck.asp", False
.Open "POST", "http://rkcny.com/RegCheck.asp", False
.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
'.send ("Registration=999100292124")
'.send ("Registration=3342344%6667")
.send ("Registration=334234456667")
Debug.Print .responseText
End With
Set msXML = Nothing
End Sub
</PhoneHome>
David W. Fenton
> On Sat, 18 Mar 2006 14:33:09 -0600, "David W. Fenton"
><XXXu...@dfenton.com.invalid> wrote:
>>Is running SQL Server or some other server db on the web server
>>not a possibility?
>
> It is. I would rather do it with SQL Server, or MySQL. It
> appears that a DAP can connect to a remote SQL Server database. .
> . .
I'm confused. An MDB can connect to a remote SQL Server database, so
why would you implement a DAP just to get to the remote SQL Server
database?
> . . . If so,
> believe (hope) I can create a hidden DAP form to be the interface
> for this licensing, update checking process. I know, I know.
> DAPs are going away in Office 12. But we should be able to
> continue using Access 2003 for at least another 2-3 years. After
> that, I'll just re-write the procedure using the Access 12
> technology. Since it's a process that's transparent to the user,
> they'll never know the difference.
I don't get what purpose a DAP would serve in a scenario where you
had a remote SQL Server connection available to your local MDB.
Lauren Wilson
<XXXu...@dfenton.com.invalid> wrote:
>Lauren Wilson <nos...@nospam.com> wrote in
>news:9ocq12ptdv3lvu4pc...@4ax.com:
>
>> On Sat, 18 Mar 2006 14:33:09 -0600, "David W. Fenton"
>><XXXu...@dfenton.com.invalid> wrote:
>
>>>Is running SQL Server or some other server db on the web server
>>>not a possibility?
>>
>> It is. I would rather do it with SQL Server, or MySQL. It
>> appears that a DAP can connect to a remote SQL Server database. .
>> . .
>
>I'm confused. An MDB can connect to a remote SQL Server database, so
>why would you implement a DAP just to get to the remote SQL Server
>database?
OK, to get us in sync: Until about 36 hours ago, I was CONSIDERING
whether or not a DAP could be used for something that I THOUGHT was
not possible without it. Either I misread earlier posts or there is
disagreement about the issue among those who posted responses.
Bottom line: You appear to be saying that it IS possible to use ADO
FROM the VBA code of an MDB (or MDE) to connect to a table in an SQL
Database on a remote web server, using an HTTP URL as a connection
string -- correct?
Until you reminded me that this might be possible, I first looked for
a way to do it with an MDB on the web server. Since I have access to
several web servers running either MS SQL Server OR MySQL, I've simply
switched my focus to doing it that way.
Lyle Fairfield
rkc
> ROFL!
You were right all along.
I should know that by now.
Lyle Fairfield
support my application.
It seems simple and quick and easily modifed from the server side by
messing with the ASP files.
And I am right in thinking that if the ASP can get at a db, any db, and
write some data, I can suck that data back into my Access or other
application? And I could send Parameters?
I'm going to have to play with this after income tax season.
I suppose I can use it from Script with the ActiveXObject too!
or even from ASP ... to ASP
Hmmmmmm ...
sounds too good to be true ... what's the catch?
rkc
It's so simple it seems like magic, but it is also what makes
the so called Ajax technology possible. All major up to date
browsers support an xmlhttp object. Microsoft as an active x
object. The others built in to the javascript support of the
browser.
Bri
Lauren Wilson wrote:
> Bottom line: You appear to be saying that it IS possible to use ADO
> FROM the VBA code of an MDB (or MDE) to connect to a table in an SQL
> Database on a remote web server, using an HTTP URL as a connection
> string -- correct?
Close, but not quite right. If you are connecting directly to the remote
server db (SQL Server or MySQL) then you can do so using the appropriate
connection string. This will NOT be a HTTP URL. For a list of all
possible connection strings (or at the very least all of the meaningful
ones) take a look at:
http://www.carlprothman.net/Default.aspx?tabid=81
From this fantastic resource (adjust to your specifics):
ODBC Driver for MySQL (via MyODBC)
To connect to a remote database
oConn.Open "Driver={mySQL};" & _
"Server=db1.database.com;" & _
"Port=3306;" & _
"Option=131072;" & _
"Stmt=;" & _
"Database=mydb;" & _
"Uid=myUsername;" & _
"Pwd=myPassword"
HTH
--
Bri
David W. Fenton
> On Sun, 19 Mar 2006 14:31:13 -0600, "David W. Fenton"
><XXXu...@dfenton.com.invalid> wrote:
>
>>Lauren Wilson <nos...@nospam.com> wrote in
>>news:9ocq12ptdv3lvu4pc...@4ax.com:
>>
>>> On Sat, 18 Mar 2006 14:33:09 -0600, "David W. Fenton"
>>><XXXu...@dfenton.com.invalid> wrote:
>>
>>>>Is running SQL Server or some other server db on the web server
>>>>not a possibility?
>>>
>>> It is. I would rather do it with SQL Server, or MySQL. It
>>> appears that a DAP can connect to a remote SQL Server database.
>>> . . .
>>
>>I'm confused. An MDB can connect to a remote SQL Server database,
>>so why would you implement a DAP just to get to the remote SQL
>>Server database?
>
> OK, to get us in sync: Until about 36 hours ago, I was
> CONSIDERING whether or not a DAP could be used for something that
> I THOUGHT was not possible without it. Either I misread earlier
> posts or there is disagreement about the issue among those who
> posted responses.
>
> Bottom line: You appear to be saying that it IS possible to use
> ADO FROM the VBA code of an MDB (or MDE) to connect to a table in
> an SQL Database on a remote web server, using an HTTP URL as a
> connection string -- correct?
No. Not HTTP -- a direct connection to the SQL Server port.
> Until you reminded me that this might be possible, I first looked
> for a way to do it with an MDB on the web server. Since I have
> access to several web servers running either MS SQL Server OR
> MySQL, I've simply switched my focus to doing it that way.
Well, I was not suggesting HTTP -- Access's capabilities in that
regard have already been completely defined in this thread. A
different back end on the server does not change that.
The only thing a server database changes is that there's a process
running on the server to connect to, which is not the case with an
MDB. If the ISP can't open up the SQL Server port, or provide a VPN
connection, then this won't work, either.
But Lyle has frequently posted about the ISPs that provide this kind
of service. I have no dealings with any of them, since I will never
buy web hosting from a Windows-based ISP, since I consider it
substandard.