In general, you have to do something like: - for newly-created files, create them during the transaction. If the transaction rolls back, delete the file. If the transaction commits, leave them alone.
- for deleted files, leave them in place. If the transaction commits, delete the files. If the transaction rolls back, leave them alone. Handling updates could be a challange, as could handling multiple inserts and deletes of the same entity within a single transaction. As you might guess, this can be an annoying thing to get right! If you have full control over the app, the best solution might be to periodically run a "BEGIN EXCLUSIVE", then review the filesystem and database state and delete any excess files, then run "ROLLBACK". This still doesn't handle conflicts in case someone wants to put a file in the same place as an existing deleted file. -scott On 9/8/07, Yves Goergen <[EMAIL PROTECTED]> wrote: > On 08.09.2007 21:06 CE(S)T, Joe Wilson wrote: > > Are you able to store this file in the database itself as a BLOB? > > No, its an input file that I'm processing and saving the results in the > database. When processing and database import are successful, the file > must be deleted so that it won't be imported again in a later run. > > On 08.09.2007 22:16 CE(S)T, Dwight Ingersoll wrote: > > Assuming the data files you are working with are of a manageable size, > > either read the file into a variable in your code and then process it if the > > file delete succeeds, or import the data file into a work table in SQLite, > > and then attempt the file delete. > > And when deleting the file works fine, but processing does not? Then the > file is gone and I need to restore it or something. My application must > not break in this time and I need to be able to recreate that file... > Storing it in a db table sound like the data is safe at any time, but > it's still not the original format. > > Well, maybe deleting to the recycle bin would be an option I could live > with. Or if all else fails, giving the database thing a priority and > only inform the user if the file could not be deleted. After all, it's > not usual that the file can't be deleted or that a database error would > occur in my particular case, but it's an interesting question in > general, I believe. > > -- > Yves Goergen "LonelyPixel" <[EMAIL PROTECTED]> > Visit my web laboratory at http://beta.unclassified.de > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
