Remotely update database

Hi,
We have a SQL Server 2000 database on an Win2k server. I'd like to
offer the facility for our customers to add records to our database
from their programs. They just want to make one function call to
create a new record on our database.
This call would return a success or failure code number.
They are not (currently) connected to our system. I had felt that a
VPN would be the best method, but am open to alternative suggestions.
Their programs run on about 100 PC's on their lan, so I figured I'd
need to write a DLL for their server which is constantly connected to
our server, then their function call would invoke a function within
this DLL. For this I'd be using VB6 (sorry, not upgraded to .NET yet).
The idea being that we would then only have one connection to our
server rather than 100.
Security is a key concern - I don't really want to provide their
programmers with the logins to our system, just a compiled DLL that
does it for them.
Do you think this is a workable plan? What would be better?
TIA
PhilHow about creating a Web Service that their programs can access. Then you
don't need a VPN at all.
Andrew J. Kelly SQL MVP
"RS200Phil" <philsowden@.dataservicesltd.co.uk> wrote in message
news:1143819451.670277.13120@.e56g2000cwe.googlegroups.com...
> Hi,
> We have a SQL Server 2000 database on an Win2k server. I'd like to
> offer the facility for our customers to add records to our database
> from their programs. They just want to make one function call to
> create a new record on our database.
> This call would return a success or failure code number.
> They are not (currently) connected to our system. I had felt that a
> VPN would be the best method, but am open to alternative suggestions.
> Their programs run on about 100 PC's on their lan, so I figured I'd
> need to write a DLL for their server which is constantly connected to
> our server, then their function call would invoke a function within
> this DLL. For this I'd be using VB6 (sorry, not upgraded to .NET yet).
> The idea being that we would then only have one connection to our
> server rather than 100.
> Security is a key concern - I don't really want to provide their
> programmers with the logins to our system, just a compiled DLL that
> does it for them.
> Do you think this is a workable plan? What would be better?
> TIA
> Phil
>|||Sounds like a brilliant solution, thanks, Andrew. Please excuse my
ignorance - where would I look for information on how to develop and
implement a web service?
I'm not afraid to get my hands dirty or read manuals. I develop
primarily in ASP and VB.
Cheers
Phil|||I think you would want .Net for this, in which case the tools do 90 percent
of the codign for you. All you need to do is write a single function that
takes parameters and .Net will code the interface. Then you could write a
DLL that would access the web service (again, .net does all the work) which
could run from their desktops or a webserver in their domain. You can do it
without .Net, it is just a lot more work.
However, they still need to be able to access your web server, on your
network, and you still need to make sure that random people on the internet
cannot access your server. So you need to have some security built in to
control access.
"RS200Phil" <philsowden@.dataservicesltd.co.uk> wrote in message
news:1143840697.760335.245570@.t31g2000cwb.googlegroups.com...
> Sounds like a brilliant solution, thanks, Andrew. Please excuse my
> ignorance - where would I look for information on how to develop and
> implement a web service?
> I'm not afraid to get my hands dirty or read manuals. I develop
> primarily in ASP and VB.
> Cheers
> Phil
>|||http://www.google.com/search?hl=en&...vice+sql+server
Andrew J. Kelly SQL MVP
"RS200Phil" <philsowden@.dataservicesltd.co.uk> wrote in message
news:1143840697.760335.245570@.t31g2000cwb.googlegroups.com...
> Sounds like a brilliant solution, thanks, Andrew. Please excuse my
> ignorance - where would I look for information on how to develop and
> implement a web service?
> I'm not afraid to get my hands dirty or read manuals. I develop
> primarily in ASP and VB.
> Cheers
> Phil
>