Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 SQL Server Administration (2005)
 Can I use Web Services to transfer data?

Author  Topic 

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-10 : 12:21:16
I know this is a rather open-ended question, but I am looking for a way to transfer data from a database on one server to another server via HTTP. Can I do this using SQL 2005 Web Services?

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2008-06-10 : 12:49:24
no. since you can't call a webservice from sql server without doing some heavy duty CLR integration.

your other options are either creating a linked server or setting up a service broker coversation between servers.

_______________________________________________
Causing trouble since 1980
Blog: http://weblogs.sqlteam.com/mladenp
Speed up SSMS development: www.ssmstoolspack.com <- version 1.0 out!
Go to Top of Page

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-10 : 13:16:04
The other 2 options, wouldn't that require a VPN connection. The client server is in Texas, and the master server is in Chicago. I plan on having 300+ client servers all transferring data back to Chicago, but I don't want to have any VPN connections. I want to transfer the data over standard HTTP port 80. Any ideas?

TIA,

Ken
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2008-06-10 : 13:44:58
service broker doesn't require a vpn connection.
you just have to open the port that you will use it.
as far as i can remember the port has to be between has to be between 1024 and 32767.
but you might want to try it over 80.
however this wont be HTTP protocol.

if you really really really need it to be http then create a small app that will do this.

_______________________________________________
Causing trouble since 1980
Blog: http://weblogs.sqlteam.com/mladenp
Speed up SSMS development: www.ssmstoolspack.com <- version 1.0 out!
Go to Top of Page

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-10 : 15:01:44
Can SQL 2005 call a third-party web service? If I were to create a SOAP web service that would accept an encrypted database and import it, how can SQL call it?
Go to Top of Page

tripodal
Constraint Violating Yak Guru

259 Posts

Posted - 2008-06-10 : 15:04:38
What exactly are you trying to transmit via the web.
And entire database, a few strings? You could use your firewall to map port 80 directly to your sql servers internal port. Making the web part of your lan.
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2008-06-10 : 15:15:45
you have to develop a solution for calling 3rd party web service by yourself in CLR and inport this in sql server.
i remember there was a quite complex sample for doing this on codeproject a while back.
but i 'd really look into other options for this.

_______________________________________________
Causing trouble since 1980
Blog: http://weblogs.sqlteam.com/mladenp
Speed up SSMS development: www.ssmstoolspack.com <- version 1.0 out!
Go to Top of Page

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-10 : 15:48:34
On a daily basis we transfer all updates/inserts (no deletions allowed) from one "on-line productivity" database (WorkTrack) to another "update database" (WorkTrack_SDP) on the same client server. We then need to send the WorkTrack_SDP database to Chicago, and import it into our WorkTrack_Master database which contains data of over 300 client WorkTrack databases.

These are on our client's networks, not ours and are not under our control and as I am sure you can understand it is very difficult to get any IT department to open any ports or allow any sort of VPN connection. I could write a SOAP Web Service in Chicago that would accept the Update Database (WorkTrack_SDP) which could be placed into an encrypted format and converted to XML. The web service would then extract the database and import it into our Chicago WorkTrack Master database. This could all be done over HTTP port 80 and that is something that we can demand of our clients. I wanted the SQL Server on the clients to create a single file of the database and send it over the web service, but I guess that cannot be done in SQL 2005. So, I guess I will create an app that will be called by SQL to perform the transfer of the database "file" over the web service.


What's the most compact and reliable single file solution of exporting an entire database? Backup?

Thanks guys.
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2008-06-10 : 15:56:43
what you need to do is this:
http://www.sqlteam.com/article/centralized-asynchronous-auditing-across-instances-and-servers-with-service-broker
it's exactly right for your scenario considering all of the security implications of your need.

yep it's backup. also one way to go is to generate the insert statements for all the tables in the database in a single .sql file, zip it and sent it to a webservice.

_______________________________________________
Causing trouble since 1980
Blog: http://weblogs.sqlteam.com/mladenp
Speed up SSMS development: www.ssmstoolspack.com <- version 1.0 out!
Go to Top of Page

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-10 : 17:26:44
Doesn't the Transport Route in the Service Broker require a port to be open on the client side? That's a problem. I want the data transport to go over standard HTTP port 80. That way only have to demand that our clients allow internet access to our web site.

I'm thinking of creating a SQL backup of the Update Database (WorkTrack_SDP) and transforming it into an 256 bit encrypted zip file, and putting that into a blob field in a Visual Foxpro table and turning that into an XML file which could be transmitted via a standard web service. Since it's encrypted, any sniffer of the xml web service transport would not be able to decipher the data.

The Web Service on the server would then reverse the process, restore the backup to a WorkTrack_SDP database on the Chicago server, and execute a SPROC that would Insert/Update the data from WorkTrack_SDP into WorkTrack_Master.

Does that sound like a good plan to you?

Thanks for your valuable time, insight and assistance!
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2008-06-10 : 17:33:59
honestly put... i don't know. backups might be quite big...
you'll have to manage network hiccups etc...

good luck with it.

_______________________________________________
Causing trouble since 1980
Blog: http://weblogs.sqlteam.com/mladenp
Speed up SSMS development: www.ssmstoolspack.com <- version 1.0 out!
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2008-06-10 : 17:39:08
I've heard you can use transactional replication over FTP. Is FTP an option?

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-10 : 17:52:07
Actually the database backups should be relatively small since they will only contain one days worth of data. The WorkTrack_SDP database tables on the client server are truncated before insertion of updated data from WorkTrack. Also it will be compressed during transport due to using WinZip Encryption.

Network hiccups are planned for. I will actually record when an SDP was sent to the server in a "SDP Control" table on each client. Also a method on the Web Service will be called to verify the previous SDP transferred was actually imported. I'm even thinking of possibly having the Web Service on the Server do the whole import shebang and return an OK/Failure message. We'll see how long it takes.

Hi Tara. No I don't want to use FTP or Replication. We already use FTP to transport Visual Foxpro databases and that has other implications (need port 20/21 open, CERN proxy server issues, etc). Plus you have to have a program running on the server to check for FTP files and import them. Also I don't like replication because it's too static. Thanks for the thought though!
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2008-06-10 : 17:53:50
Replication is certainly not static. We use it for a mission critical process that requires the data to replicate in near real-time.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

sodeep
Master Smack Fu Yak Hacker

7174 Posts

Posted - 2008-06-10 : 19:17:02
You would probably want to transfer data with FTP in Replication.Thats basically faster than TCP/IP or other means.
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2008-06-10 : 19:35:30
Is there an echo?

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

sodeep
Master Smack Fu Yak Hacker

7174 Posts

Posted - 2008-06-10 : 19:38:05
Yes Tara, I see that.
Go to Top of Page

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-11 : 07:47:39
Sorry me bad word. By Static I meant that when using replication it's difficult to manage database schema changes because you have to change all of the subscribers/publishers to match the new schema. I foresee some of these 300 clients having additional tables/columns where others may not. As long as the master database contains a schema for all clients I can import the data via scripts based on the client schema. I can't do that when using replication - the publisher db schema must match the subscriber db schema - correct?
Go to Top of Page

tripodal
Constraint Violating Yak Guru

259 Posts

Posted - 2008-06-11 : 10:33:34
You could set the client servers to run a second nightly backup, then schedule a windows task to nightly ftp the file to your main location.
Out going 1 way connection should not have any issue with the vast majority of firewalls. If that was still an issue, you coudl use a webserver hosted on yourside and post the file through it. I believe all of that could be easily eneough done with a simple batch file. YOu could even configure it to telnet an email to you with the results daily.


Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2008-06-11 : 11:17:22
quote:
Originally posted by Ken Blum

Sorry me bad word. By Static I meant that when using replication it's difficult to manage database schema changes because you have to change all of the subscribers/publishers to match the new schema. I foresee some of these 300 clients having additional tables/columns where others may not. As long as the master database contains a schema for all clients I can import the data via scripts based on the client schema. I can't do that when using replication - the publisher db schema must match the subscriber db schema - correct?



That isn't true in SQL Server 2005. Schema changes now get replicated.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

Ken Blum
Constraint Violating Yak Guru

383 Posts

Posted - 2008-06-11 : 11:37:06
Thanks again Tara. I will definitely consider Replication in the future. If there was a way to perform replication via HTTP port 80 I would consider it. I just can't demand that our clients open ports on their firewall for VPN/FTP. For now I think I will handle it by transferring the data I need via a web service.

Tripodal: Good idea, but as I stated before we already use FTP to transfer VFP databases. There are also firewall/proxy server issues when using FTP, and I am trying to avoid that.
Go to Top of Page
    Next Page

- Advertisement -