March 25, 2013 at 10:35 am
Hi All,
Please i need an answer to this question. I have two servers, one locally and one hosted, i normally upload data to the online one using data export wizard. but the local database is now connected to an application that adds data to it almost every second.
This is what i want to do
1. write a trigger for insert that will insert the data to the hosted server(database) anytime the local database table is added with data(pardon my English)
2. Is it posible to do upload data from a local database to an online database through a trigger, a sample script will guide me through.
Thanks
Tim
March 25, 2013 at 10:55 am
timotech (3/25/2013)
Hi All,Please i need an answer to this question. I have two servers, one locally and one hosted, i normally upload data to the online one using data export wizard. but the local database is now connected to an application that adds data to it almost every second.
This is what i want to do
1. write a trigger for insert that will insert the data to the hosted server(database) anytime the local database table is added with data(pardon my English)
2. Is it posible to do upload data from a local database to an online database through a trigger, a sample script will guide me through.
Thanks
Tim
while technically possible, it's not worth it;
if the remote server is unavailable, the trigger would fail, and you would lose the data in both the local database(due to transaction rollback) and at the remote as well.
you've already got someway to determine what is new, so you want to use something like Replication to get the data to the remote server instead; Other possibilities could be using Extended events or a scheduled job to get the changes moved as well; it really depends on the job .
Have you looked into replication at all? it's very easy to set up, lots of examples out there, and once it's set up, SQL does the work for you.
you can replicate one table, or the whole database if needed.
Lowell
March 25, 2013 at 10:59 am
lol, your reply made me laugh, i.e the its not worth it part.
Alright, i'll google replication and see what i can come up with.
thanks
Tim
March 26, 2013 at 8:38 am
Depending on how many tables you have I would also look into having the triggers simply put the primary key for each table into a table that is used to drive a separate process that will iteratively move new records over to the off-site machine. This can be much easier and less risk/trouble than replication if you don't already have experience with that subsystem, which it sounds like you don't. I have used this mechanism many times in the past to do what you are looking to do, and also to do other things such as incremental data warehouse populations.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
March 26, 2013 at 8:57 am
Thanks Kevin, are u suggesting i use Triggers with a unique id?
You said you have been doing something similar, can u please shed more light
Thanks
Tim
March 26, 2013 at 1:18 pm
timotech (3/26/2013)
Thanks Kevin, are u suggesting i use Triggers with a unique id?You said you have been doing something similar, can u please shed more light
Thanks
Tim
It is a simple trigger concept that simply puts the PK for a table into a "driver" table that is read by the process that actually migrates records to the other server.
Pseudocode:
myTable:
field1 int identity primary key,
field2 varchar(10) not null,
field3 datetime not null
myTableDriver:
field1 int
trigger for insert on myTable:
insert myTableDriver
select field1 from INSERTED
sproc migrateMyTableToOtherServer:
insert myOtherServer.myOtherDatabase.dbo.myTable
select *
from myTable mt inner join myTableDriver mtd on mt.field1 = mtd.field1
delete myTableDriver
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
March 26, 2013 at 1:26 pm
a trigger featuring a linked server was what i was suggesting to avoid; network problems or permissions issues related to which remote user is used to insert into the remote server could result in the loss of the data being inserted;
admittedly, with some solid design and testing, the permissions issue could be mitigated. but if the remote server is not on the same LAN, I'd worry about connectivity problems.
a trigger inserting data inserting into a local table, say "RecordsToProcess", and having some seperate job loop thru those records, and marking records successfully processed with some indicator, would be much better;
if the changes that occurred in the regular table can be identified without the trigger, that's even better, but it depends on the details.
Lowell
March 26, 2013 at 1:34 pm
Sounds like a poor man's version of Service Broker. Not a bad idea, considering the steep slope of knowledge needed to get Broker up and running properly.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
March 26, 2013 at 2:27 pm
I have done this type of processing for at least 15 years, probably more. Works fine, lasts a long time! 😎
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
March 26, 2013 at 4:31 pm
Guys, i'm getting more confused here,
which way i'm i to go?
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply