Connecting to a database remotely over the internet.

Connecting to a database remotely over the internet.

Post by QW5kcmV » Sat, 07 Oct 2006 23:50:02

I wanted to know what was the best or common practice for connecting remotely
over the internet to a database on a website or server from a vb6 or

How can I connect to a ms access mdb database or a 2000sql database through
IIS or can I get around IIS?

Does anybody have white paper, websites information or code examples that
describe how to do this in the simplest or most common ways?

I have read some about Remote Data Object, is that any good?

I also have read about passing posting information to an asp page to
process, and then returning it with xml.

Connecting to a database remotely over the internet.

Post by Ralp » Sun, 08 Oct 2006 00:32:46


You can use a ton of various technologies. I generally perfer SOAP as the
simplest and easiest way.
Google for "SOAP Internet Applications"

If you are going to stay with M$ start here...

Can you get around IIS? - Sure. Can you roll 'r own? - Sure. It is really a
matter of how universal (enterprise-wide) you want your access technologies
to be, how much ownership you have of both ends, what you're trying to do,
avaliable resources (programmers, wire, boxes, ...), and how much time (and
money) you want to spend.

There are a ton of factors and issues (some physical, some political)
associated with whatever tool you use. There is isn't one major, OSFA,
giant, killer technology out there. (In spite of all the hype. <g>) You will
likely end up with a mix.

RDO is dead!



Connecting to a database remotely over the internet.

Post by Schmid » Sun, 08 Oct 2006 07:45:02

"Andrew" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

Most common for VB-Classic-Users is probably, to go through Asp-Pages,
hosted by a MS-IIS, instancing COM-Objects at the serverside from VB-
ActiveX-Dlls inside the Asp-Script(s).
At the clientside you would have to translate Parameters and Return-Values
yourself with the help of some http-request-COMponents then.
But of course, this approach is somewhat outdated.

Most common nowadays is, to work over SOAP-Requests against the
serverside. Many languages support SOAP-Requests over a set of
Client-Libraries or Classes - but VB-Classic has nothing in this regard
directly built in.
There's the MS-SOAP-Toolkit, offering SOAP-Client-support for COM-
Classes and there are free 3rd-party Client-Tools too (e.g. PocketSoap).
At the serverside SOAP is supported by many WebServers/Appservers,
and there are serverside SOAP/(D)COM bridges too.

For both approaches you would have to use SSL, if you want to
secure the communication, going over public internet (buying a SSL-
Server-Certificate, manage SOAP-Client-Certificates) wich brings
a lot of trouble into the game.

The *simplest* way (from my point of view) is, to implement the requests
using our free RPC-Tools. These work over a binary protocol, wich is
proprietary, but very fast - optimized, to serialize and transport all
VB-Types (Dates, Longs, Doubles, Strings, Variants, Bytes, etc. + the
appropriate VB-Arrays of all those types).
You simply implement the Serverpart as an ActiveX-Dll and can access
Methods of Public-Classes in this Dll at the clientside writing code this

'a wrapping-method with exactly the same signature like its pendant
'inside the server-dll (Params and Returnvalue)
'here retrieving a disconnected ADO-Recordset from a serverside DB
Public Function GetADORecordset(CnnString As String, SQL As String) _
As RecordSet
On Error Resume Next
'Now the RPC with a TimeOut of 5 seconds...
'just place the Param-List in correct order at the end of the call
Set GetADORecordset = Cnn.RPC SrvDllName, SrvClassName, _
"GetADORecordset", 5, CnnString, SQL)
End Function


Connecting to a database remotely over the internet.

Post by Mike Sciro » Sun, 08 Oct 2006 13:34:01

Please post a url for the "free RPC-Tools" if you would, I'm interested
in learning how to do this from VB6 too.


Connecting to a database remotely over the internet.

Post by Schmid » Sun, 08 Oct 2006 22:04:00

"Mike Scirocco" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

Here's a download-link to the RPC-Tools:
including a well commented Demo, that includes RPC-Requests
of all possible VB-Types (Strings, Arrays, ADO-Recordsets).
This Demo is working without Authentication and Encryption
per Default, to keep things simple regarding successful testing.
No installation/registration needed, simply copy the
appropriate Client- and ServerFolders from the Zip-File
to e.g. C:\RPCTools\Server and C:\RPCTools\DemoClient.
Then start RPCServer.exe from the Server-Folder and click on
the Start-Button in the upper right corner - now the Button should
went green, signaling that the underlying service is up and running.
Now start RPCDemoClient.exe from the ClientDemo\Bin-Folder,
click connect and play around with the various Calls.

Now here comes Code for a Client-Demo, that works against
NWind.mdb hosted at our own server at '':
This Demo works with full authentication, encrypted and compressed
over public internet, to give you an impression of the RPC-Performance
working in a true internet-scenario.
I've just started the RPCServer-Part on our host and let it run a few
days from now on.

Let me know, if you have any problems with the examples, or if you
want to setup the RPCServer, to run the server-part of the NWind-
DBDemo on your own host (there are some settings needed in the
RPCServer.Ini, to force Authentication, create a Client-Certificate,


Connecting to a database remotely over the internet.

Post by Schmid » Mon, 09 Oct 2006 00:21:17

"Ralph" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

Yes, other than DCOM (wich works over a huge Range of Ports),
our Implementation works/listens on a single Port only.
If you open your serverside firewall for this RPCServer-Port,
then all should work flawlessly.
The Default-Port is 22222, but you can set any Port you want in the

To avoid problems with clientside Firewalls, wich sometimes are
configured to block "unknown Ports" even for outgoing connections,
you can set the RPCServers Port to e.g. 80 (the http-defaultport).
This way you can avoid those potential clientside firewall-problems
(of course the RPC-Host shouldn't run a Webserver, listening on Port 80
at the same IP then).

Our underlying protocol is not http-based, but the server can answer
http-requests with a simple Status-Message - so there's no problem
that the server will crash with "unknown protocol", due to eventually
incoming http-requests over Port 80 from "normal WebBrowser-Clients".
You can check the http-responsibility of our running server (currently
listening on the Default-Port 22222) with your Browser entering
this URL: :22222


Connecting to a database remotely over the internet.

Post by Jim Carloc » Mon, 09 Oct 2006 00:53:02

"Ralph" < XXXX@XXXXX.COM > schrieb:


To add to what Schmidt mentioned... I just tested the Client side
out and the firewall asked if I wanted to give the application,
"RPCDBDemo.exe" permission to access.

I imagine the server app gets detected by the firewall in a similar
fashion but I haven't gotten to that as of yet. The firewall might
not say anything though until someone tries to connect to it. It
really depends upon the firewall in question and that's a whole
topic where you'll get all sorts of different stories.

"Microsoft's XP SP2 firecall (?)" failed to notice the client program
trying to phone home, so I hesitate to call it a firewall.

Hope this helps.

- -
Jim Carlock
Post replies to the group.

Connecting to a database remotely over the internet.

Post by Schmid » Mon, 09 Oct 2006 01:54:12

"Jim Carlock" <anonymous@localhost> schrieb im Newsbeitrag

Yep, Personal (Software-)Firewalls are often configured, to work in both
directions (outgoing connections and incoming connection-attempts).
The most "Hardware-FireWalls" (e.g. on a DSL-Router) are configured
by default, to block (or forward if allowed) only incoming connections.

If one is installing our RPC-Services on a Server-Host, than he should
of course configure its Hard- or Software-Firewalls appropriately (Port-
Forwarding and/or Routing, etc.), followed by some (Stress-)Tests of
course. Doing so doesn't leave much room for surprises.

Don't know the features of the builtin XP-FW - but as said above,
that's not an uncommon behaviour, to allow outgoing connections
on any port. Wouldn't be surprised, if the XP-FW would have an
option somewhere, to watch/filter those outgoing connections too
(in addition to the incoming attempts).


Connecting to a database remotely over the internet.

Post by Mike Sciro » Mon, 09 Oct 2006 03:58:14

Thanks very much!