To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=62664
------- Additional comments from [EMAIL PROTECTED] Mon May 22 03:46:20 -0700 2006 ------- > * there is a bug here anyway - using UTF-8 in an un-controlled way Yes. Wasn't aware that this might really happen, but yes. > * tons of languages can't store biblography entries currently > * we want databases that can store the full Unicode range, not some > random sub-set > * short / fixed-length fields are pretty evil anyway Doesn't all of this sound like "dBase is the wrong backend for the Bibliography database"? (or, if you want, for any database which requires more than stone-aged ASCII compatibility) > Sure - that will happen - but of course, only for dbase databases, with > short fixed length record sizes: a fairly small target combination anyway > IMHO. "short" is not the point here. We would have the problem for every dBase database were the designer deliberately chose a certain field length, and the user tries to use exactly this field length. Quite common, IMO, since for dBase "databases" the designer and the user are more often than not the same person. I'm not against allowing Unicode for dBase, but I'm against replacing once quirk with another, just shifting the problem to other areas this way. If we'd allow UTF-8, we need at least a useful error message in case the entered text is cut. I.e., instead of silently shortening the text to what fits, the update operation should be rejected, with an error message telling what's going on. Ideally, we would also issue a warning when the user changes the encoding to some non-fixed-byte encoding, but that's much less important. > So - how about it ? :-) I'll knock up a patch Go on - including the error message, please :) You already found the right place to fix, and throwing an exception is even easier than properly cutting some UTF-8 characters. Note that DBTypeConversion::convertUnicodeString already returns the length of the converted string. When throwing an exception, please use an SQLState of 22001 (which according to the SQL standard classifies as "data exception" with sub condition "String data, right truncation"). Thanks. --------------------------------------------------------------------- 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]
