To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=94644
------- Additional comments from [EMAIL PROTECTED] Mon Oct 6 14:09:06 +0000 2008 ------- well I have not trusted in the abilies of OO.o to write .dbf since ..., however, I took the oportunity to recheck, how OO.o is witing .dbf- files summary of the desaster - a showstopper the test-procedure is: application produces .dbf - opend in OO.o - saved and reopend/reimported in application short summary of the mistakes: - length/offset-infos in dbf-header: stripped - record-counter wrong - Labels changed (here: CP 437 high bytes not used ( Ä ==> _) - numeric : N 0 = N 2 ( N2 means N.NN) - change of keyboard-layout (very strange: CP 437 on Import gives " for a-umlaut) To me, re-import gaves error-codes but I can read the data. But, it was impossible to reuse the forms. All in all, there are some smart features within the dbf-storage from OO.o, that actually are not related to .dbf-files and need to be stopped. HOWEVER - the more importend is: Supposed you open a wellformed .dbf and edit and close it, it is converted in the above stated manner - and from thereon you have a fragmented unreadabler waste. So it is either a showstopper - or you need to publish the inability to deal with .dbf-files. Martin tested in here with ooo300m7 on Win2K --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
