Hi Daniel, > That's a good hint. I experimented with Connection.close(), but it > didn't solve the problem.
Hmm, I would have expected this to implicitly flush the changes. > But freeing the DataSource with > DataSource.Dispose() seems to work. Not a good idea, see below. > Now (cached) changes to the DB are > written to the odb-file. And the lock gets removed - I suspect a > locking-problem to be responsible for the crash of the windows-version. I don't have time trying at the moment, but the lock file should be removed, too - basically, it indicates that there is an open connection to the database. Assuming that your code is the only client which accesses the database, disposing your connection should also remove the lock. Or is it that there are other places (the same DB doc opened in a window? Other Basic code? An open data source browser displaying some table?) which access the DB doc or the data source? > However some uncertainty remains. I can't figure out from the > documentation when a close() or a dispose() is necessary and when not. > For example Dispose()-ing the DB-Context doesn't seem to be a good idea > as one has to restart OOO then to open a new DB-Connection ... So are > there any rules when to Dispose() and when not? First, for a connection (and this is special to this object, /not/ a general rule), "close" is equivalent to "dispose". So, let's talk about dispose only. In general: Dispose objects when you *own* them, don't dispose them if you don't. A connection obtained with getConnection is yours, you are responsible for freeing - i.e. disposing - it. The DBContext isn't yours - it is a global object, existing in a single instance only, available to the complete OOo application - so, do not dispose it, or be punished with an unstable OOo. As for the data source: They're shared objects, owned by the database context. So, you should not dispose them - is it perfectly possible that some other instance - e.g. the data source browser, a mail merge operation, or some such - holds the data source, too. >> So, some kind of flushing is necessary. This is inconvenient, but in >> the above sense, expected behavior. > > Good to know, because neither the Basic Programming Guide nor the > API-reference state this necessity to flush(), close() or dispose() and > it seems to be unique to the HSQLDB-Backend. Seems to be at least > confusing to me. That's because HSQL is the only backend which stores the data in the .odb file - for database where this is not the case, flushing is not necessary by definition. >> If you can create a small self-contained .odb (including the macro) >> showing this, please submit an issue at >> http://www.openoffice.org/issues/enter_bug.cgi?component=Database%20access. >> Feel free to assign it to me (fs). > > I hope DataSource.Dispose() will solve this issue, but I will figure > that out after holidays (no windows at home). Is it ok to post (odb-) > attachments to this list? They should come through, however - at some point in time, an issue is needed, anyways. So I'd prefer you submitting the issue, and atttaching the .odb there. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
