On Tue, Aug 5, 2008 at 4:36 PM, Till Steinbach <[EMAIL PROTECTED]> wrote: > Hi Ingo! > Although I'm limited to C-Code your code would be really useful for > me. The triggers will be the same for me. When I have the right > triggers the most difficult part is done. The idea with the seperate > table for logging is great. I have no idea yet how to log whole > statements. I'm looking forward to see your code. > > greetings Till
Side note: I once looked into using rsync to reduce remote firmware update times for an embedded device over a slow link, and I found just what you were finding -- rsync's overhead is HUGE unless you're dealing with tens or hundreds of megabytes. That said, these devices can also be configured remotely, and they can also request a refresh of all their configuration settings in the event of a problem. The way I accomplished this is by giving each setting a "dirty" flag. When the setting is changed for any reason, the "dirty" flag is set. When the device reports in (so I know that it is still working), it checks for any "dirty" settings and includes them in the report. When the server they report to receives and stores those settings, it sends back a response indicating such. Upon receiving that response, the device clears the "dirty" flag for all settings. This scenario works fine so long as it is impossible for a setting to be changed while the device is reporting in. This is possible for my devices, but it may not be for yours. If that is the case, then a more sophisticated solution will do the job: First, create a table called "generation": create table generation ( id int AUTOINCREMENT not null primary key, -- the autoincrement is kind of important here date date not null default(current_timestamp), reported int not null ) Then, when a configuration row (or other row that needs to be tracked) is to be inserted/changed, do the following steps: 1. Get the max(id) from generation where reported=0. 2. If that's null, insert a new row into generation with reported=0 and get the new row ID 3. Insert/update the relevant row, including generationId=<new row ID> When the device needs to report in: 1. If the 'generation' table is empty, there is nothing to do. Stop now. 2. Select the maximum generation ID from the 'generation' table. We will call this generation G. 3. Mark every generation with ID <= G.ID as reported. 4. Report in, including all rows with generation.Id <= G.ID 5. If the server confirms receipt of the data, delete all rows from generation where generation.Id <= G.ID That *should* make sure that no row gets missed, but I'd feel better if somebody else could sanity check and confirm. -- -- Stevie-O Real programmers use COPY CON PROGRAM.EXE _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
