Thanks to all for the answers. I will analize then and work in it...
2006/9/5, John Stanton <[EMAIL PROTECTED]>:
You could use brute force and ignorance. Keep a master copy of your database in SQL form and do a diff on the SQL form of the new DB, then export the changes as SQL to update the remote DBs. You may have deletions and update and would need to take them into account when you are doing the diff. Juan Perez wrote: > 2006/9/5, JP <[EMAIL PROTECTED]>: > >> Assumming that the clients will NOT change the original database, I can >> think of 2 methods: >> >> 1. Whole DB: drop all indices, then vacuum, then zip, then propagate. On >> the clients (suscribers), unzip, re-create all indices. >> >> 2. Incremental, add a field to stamp the date on all your records, then >> export to a separate database (zip it). On clients, apply the changes. >> >> 500k records don't say much - how big (in MB) is your DB? I can also >> suggesst changing just the FTP site to another ISP who has unlimited (or >> a very large GB monthly limit). > > > The database is downloaded zipped yet. The database Zipped has 100 > MB. The problem is that some commercials uses RTB connections, because > there are in route. Download of 100 MB is too long... > >> >> jp. >> >> Juan Perez wrote: >> > (excuse me for the other mail, i clicked accidentally the button...) >> > >> > Hi: >> > >> > I think that i explained me bad. >> > In my work i do next until now: >> > >> > Phase 1: I generate automatically a database from a CRM >> > Phase 2: I put the database in the FTP for the commercials of the >> > enterprise. They are located in different parts of the country. >> > Phase 2: The commercials uses my applicaction with the database to >> work. >> > >> > The problem is that now, the datasase is too big (and we pay the FTP >> > to an ISP for the used size and the consumed wide of band). So, i now >> > want to change the process to: >> > >> > Phase 1: I generate automatically a database from a CRM >> > Phase 2: As I already have the previous database, i will generate a >> > diff file in the format i explained in the previous mail. >> > Phase 3: I put the little diff file in the FTP ant the commercials >> > downloades it.. >> > Phase 4: The commercials brings up to date the database using my >> > application (it needs to be changed to do it). >> > Phase 5: The commercials can use my applicaction with the new database >> > to work. >> > >> > So, the question is ¿how to do, in the best way, the new phase 2? >> > >> > 2006/9/4, Juan Perez <[EMAIL PROTECTED]>: >> >> Hi: >> >> >> >> I think that i explained me bad. >> >> In my work i do next work: >> >> >> >> I generate automatically a database from a CRM >> >> >> >> 2006/9/4, Paul Smith <[EMAIL PROTECTED]>: >> >> > At 16:48 04/09/2006, you wrote: >> >> > >Hi all: >> >> > > >> >> > > I have developed a program that uses a sqlite database. >> >> > > Until now the users downloaded an entire new version of the >> >> > >database weekly from the FTP server. >> >> > > But now the database is too big (about 500.000 records) and i >> want >> >> > >to make a database actualization system. >> >> > > So, what is the best way (having the old database and the new >> one) >> >> > >to obtain a file with the differences. Something like this: >> >> > >> >> > Hmm, I don't think I'd do it that way. If you do that, then you need >> >> > to have a copy of the old & new database to compare. >> >> > >> >> > One way around it is to have a 'journal' table which just contains >> >> > all the SQL queries which have been actioned (you have to take care >> >> > if you use transactions) along with an incrementing serial number. >> >> > Then, the user's software can say 'I have all journal entries up to >> >> > 252376', and then you can just given them all the journal entries >> >> > after that number, and they can run the SQL on their end. which will >> >> give. >> >> > >> >> > You can make your routine which modifies the database just keep a >> >> > copy of the SQL used whenever the action succeeds, and store that in >> >> > the Journal table. >> >> > >> >> > >> >> > >> >> > Paul VPOP3 - Internet Email >> Server/Gateway >> >> > [EMAIL PROTECTED] http://www.pscs.co.uk/ >> >> > >> >> > >> >> > >> >> > >> >> >> ----------------------------------------------------------------------------- >> >> >> >> >> > To unsubscribe, send email to [EMAIL PROTECTED] >> >> > >> >> >> ----------------------------------------------------------------------------- >> >> >> >> >> > >> >> > >> >> >> > >> > >> ----------------------------------------------------------------------------- >> >> > >> > To unsubscribe, send email to [EMAIL PROTECTED] >> > >> ----------------------------------------------------------------------------- >> >> > >> > >> > >> > >> >> >> ----------------------------------------------------------------------------- >> >> To unsubscribe, send email to [EMAIL PROTECTED] >> ----------------------------------------------------------------------------- >> >> >> > > ----------------------------------------------------------------------------- > > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
