> Where do the <file cretion date> and <file modified date> come from? > Where do the <segment name> and <description> come from? > Where does all the data to create the new records come from? You say > Process A only has a FilePath as input.
> Where do the <file cretion date> and <file modified date> come from? > All the Information written into the database is extracted from the file itself. The Segments data is also available within the file itself. We manually append these information when we save the file. > What do you mean by the line that says "Info Values)"? > It is just the information retrieved from file. > > It seems strange to change the creation date for an update. I would > think this should only happen when the record is created in step d. Yes. Can't imagine how did I do this silly thing. > Where is this "set of files" coming from? The query in step a returns > results for a single file only. Process A takes a FilePath parameter, > the same as used in the where clause in query above I would assume. >> "SELECT * FROM Segments,File WHERE File.FileID = Segments.FileID AND >> File.FullPath = <File A>; >> > > This will return the primary key for each segment associated with the > file. With that you can get any other info about the segment that may be > needed. Yes, that is what I need. I require all the information matching the given file. >> >> C) Repeat Step a) >> > > This is where you say you are having problems, correct? Are you saying > that you are not getting the same segments for the file FileA after > running process A with a parameter value of FileA? > > This is unexpected since you say Process A only updates existing rows if > the file FileA exists. It only adds new rows if FileA doesn't exist. But > if FileA doesn't exist when you run Process A then there would have been > nothing to return from the query in step a above, so any new rows would > be expected. If the file exists, then you update some column values, but > not the values that are used to select the results in the query in step > a above, so the results should be the same. > > Is there more stuff happening elsewhere that you haven't described? Are > the file and/or segment rows ever deleted? > Yes, the segments rows which are not updated are also deleted. This happens only when I do some large inserts/updates continuously i.e add/update file info and request for the updated as well as old data. I think there is some concurrency issues at my side. Now I have to re-visit to in what order are these inserts & selects are performed actually. > Process A knows it will write later, so the reserved lock at step a lets > others continue to read until it gets to step c or step d. The advantage > of this is that it prevents some other process form executing a delete > between your steps a and c for example. If the file existed when your > process A did its existence check as step a, but didn't exist when it > got to step c, there would be problems (not the problems you are seeing > though). It is probably a good idea to acquire the lock (i.e. start the > immediate transaction) before you start reading the database though. Just I tried to have an EXCLUSIVE lock in Process A just to ensure that writer process doesn't have to wait for reader process, and from that time onwards I am not getting this issue, atleast till now. But I cannot sign it off, treating this as the required change. Will look exactly what is happening. Since I am seeing this problem after upgrading it to 3.4.0, I thought its better to ask the list whether there were any known issues regarding database corrupt. Thanks for all your inputs, Will feedback what exactly is the case after I fix it, so that another person will get to know if he encounter with similar issue. -- Bharath On 3/18/08 12:59 AM, "Dennis Cote" <[EMAIL PROTECTED]> wrote: ----------------------------------------------- Robosoft Technologies - Come home to Technology Disclaimer: This email may contain confidential material. If you were not an intended recipient, please notify the sender and delete all copies. Emails to and from our network may be logged and monitored. This email and its attachments are scanned for virus by our scanners and are believed to be safe. However, no warranty is given that this email is free of malicious content or virus. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
