Subject | is "UPDATE or INSERT" the best way to replicate a read-only local table ever? |
---|---|
Author | emb_blaster |
Post date | 2011-06-20T21:52:40Z |
Hi,
Our application work with two databases same time. One in Server, and another local to be used if Our network go off-line. One of the tables hold products information, and his local copy is read-only.
We are wondering what are the bests ways to update the table (or replicate it, if you prefer this words) with the data from server.
Actually we do a "select everyone" from server create a script to do a mass "update or insert" and then run the script.
We could also do a local mass delete and then a mas insert with the almost same script (it would be not an "update or insert", but just "insert" statements).
We thought about do a parametrized query (as SET suggested days before in another thread message/114093) but we're not sure that we will gain in performance letting the transaction with the server open till we do the mass insert. Are we wrong?
Any info on what are the best methods?
note: this table will never be more than 50.000 rows, as we expect.
Our application work with two databases same time. One in Server, and another local to be used if Our network go off-line. One of the tables hold products information, and his local copy is read-only.
We are wondering what are the bests ways to update the table (or replicate it, if you prefer this words) with the data from server.
Actually we do a "select everyone" from server create a script to do a mass "update or insert" and then run the script.
We could also do a local mass delete and then a mas insert with the almost same script (it would be not an "update or insert", but just "insert" statements).
We thought about do a parametrized query (as SET suggested days before in another thread message/114093) but we're not sure that we will gain in performance letting the transaction with the server open till we do the mass insert. Are we wrong?
Any info on what are the best methods?
note: this table will never be more than 50.000 rows, as we expect.