| Subject | Re: is "UPDATE or INSERT" the best way to replicate a read-only local table ever? |
|---|---|
| Author | emb_blaster |
| Post date | 2011-07-01T20:31:20Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
I'm thankful for your reply, specially knowing that you are busy.
a)-> It's a normal database. What I mean is that the application will not change that table in any way after get the changes from SERVER.
Let's imagine it like a table for goods in a big store (not that big, just 5 'cash machines').
So in all cash machines they use that table, but the person in the cash will never do a change in the product data.
They will never change the price locally. You could just make the application take the data from the SERVER. But if the network broke, then all the computers will fail. So we have a local table if that data.
When the server add or change the data, every client will be warned by events. So they decide if will update local tables or not. This time too, the server put in a table the last time it changed.
When an application start, they check the SERVER to get the most recent data, but before, they check that param and compares to last time updated.
We know that we could do a specific control of the clients computers and a much more elaborated list of the changes made in table of the server (a journaling). But that will add much more complexity to process. We would have to check the kind of EACH update/delete/insert on SERVER table. Also will need to know if all the clients already did the update, and so on...
Thus, we know that we will not have the most optimized process in data transfer point of view. But also, it will not be the more complex in development either.
Anyway, this table will not be a big table. We know that it will not be greater than 90000 rows.
Hope that I was more clear now...
Regards,
>hi Helen,
> At 09:52 AM 21/06/2011, emb_blaster wrote:
> >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.
>
> Sorry I don't have the time to help with this right now but, seeing the thread, I wonder --
> (a) what you mean by "his local copy is read-only". Is it a read-only database? Or are you just limiting the write privileges for this user on this table?
>
> and (b) if it is a read-only database, how do you plan to update/insert/delete by any means, whether by ad hoc requests or by a proper replication scheme? Maybe total replacement of the database file at intervals or on request?
>
> ./heLen
>
I'm thankful for your reply, specially knowing that you are busy.
a)-> It's a normal database. What I mean is that the application will not change that table in any way after get the changes from SERVER.
Let's imagine it like a table for goods in a big store (not that big, just 5 'cash machines').
So in all cash machines they use that table, but the person in the cash will never do a change in the product data.
They will never change the price locally. You could just make the application take the data from the SERVER. But if the network broke, then all the computers will fail. So we have a local table if that data.
When the server add or change the data, every client will be warned by events. So they decide if will update local tables or not. This time too, the server put in a table the last time it changed.
When an application start, they check the SERVER to get the most recent data, but before, they check that param and compares to last time updated.
We know that we could do a specific control of the clients computers and a much more elaborated list of the changes made in table of the server (a journaling). But that will add much more complexity to process. We would have to check the kind of EACH update/delete/insert on SERVER table. Also will need to know if all the clients already did the update, and so on...
Thus, we know that we will not have the most optimized process in data transfer point of view. But also, it will not be the more complex in development either.
Anyway, this table will not be a big table. We know that it will not be greater than 90000 rows.
Hope that I was more clear now...
Regards,