Tim Dudgeon <[email protected]> writes: > Dag H. Wanvik wrote: >> >> It looks as if the creating of a temporary file failed. Does the path >> exist >> (C:\Users\Csizi\Documents\IJCProjects\ijc-project\.config\localdb\db\tmp), >> and if so, is it writable for this account? >> >> Dag >> > > Yes, the user has confirmed that this directory does not now exist: > C:\Users\Csizi\Documents\IJCProjects\ijc-project\.config\localdb\db\tmp > > but that its parent directory does exist, and does have write access > (but this is Vista so strange things could be happening!). > > I would imagine that the tmp directory would be created automatically > by Derby when it needed it. It is not normally present.
Yes, there is code that's supposed to take care of that right before the code that fails, and it's supposed to throw an exception if the directory cannot be created. Perhaps there's something that's removing the directory (but I didn't think Derby would remove the directory except when performing a clean shutdown of the database). FileNotFoundException is the only kind of IOException RandomAccessFile's constructor is allowed to throw, and the javadoc states that it can be thrown "(...) or if some other error occurs while opening or creating the file", so the problem could really be anything I/O-related. > What would the cause of generating the temporary file? The stack trace indicates that this happens during a cascading delete operation (deleting a row that is referenced from another table with ON DELETE CASCADE). For this kind of delete operations, Derby uses deferred deletes and needs to keep a list of rows to delete until it's ready to perform the actual deletion. The list of rows is kept in a temporary conglomerate/file. -- Knut Anders
