[firebird-support] non us characters in comments fail
Folowing procedure update fails apparently because comment contains non us character 'ä'. Goes through without 'ä'. Should this be so? Pekka unsuccessful metadata update MODIFY RDB$PROCEDURES failed while executing: ALTER PROCEDURE P_KASITTELE_VUOKRAAIKA returns (LID Integer, DS Date, DU Date, VAG VarChar(38), HINTA1 Double Precision, HINTA_L Double Precision, KD Date, FK Integer, FK2 Integer) AS BEGIN /* Procedure body */ FOR SELECT LAITE_ID, SISAAN_AIKA, ULOS_AIKA, VUOKRAAIKA_GUID, HINTA_1, HINTA_L, KASITELTY_PVA, FL_KASITELTY, FL_KASITTELY2 FROM LAITE_VUOKRAAIKA WHERE (FL_KASITTELY2 1) into :LID, :DS, :DU, :VAG, :HINTA1, :HINTA_L, :KD, :FK, FK2 DO BEGIN if ((FK = 0) and (DS is NULL)) THEN /* Some Comment ä */ BEGIN UPDATE LAITE_VUOKRAAIKA set LAITE_VUOKRAAIKA.FL_KASITELTY = 1, LAITE_VUOKRAAIKA.KASITELTY_PVA = CURRENT_DATE, LAITE_VUOKRAAIKA.FL_KASITTELY2 = 2, LAITE_VUOKRAAIKA.HINTA_L = (SELECT LAITE_PVAHINTA_L FROM LAITE WHERE LAITE.LAITE_ID = :LID) WHERE LAITE_VUOKRAAIKA.VUOKRAAIKA_GUID = :VAG; END END SUSPEND; END
Re: Odp: [firebird-support] Request for advice
On Fri, 25 Apr 2014 07:01:31 +0200, Thomas Beckmann thomas.beckm...@assfinet.de wrote: You are right: Blobs are stored in separate pages. But having blob fields inside tables with other fields forces these pages to be allocated when record is created - whether the blob will contain data or not. Blob pages are only allocated when a blob is created and filled, so if you insert a record where the blob field is null, then no additional pages get created. Furthermore, common (bad) practice of fetching all fields (select * from), sometimes even performed by database access layer of programming language against the developers wish, accesses this data and decreases performance. That is only if you actually access the blob (as in: get the blob id and then proceed to load the blob), or use an access component that does this automatically for you. Mark
Re: [firebird-support] non us characters in comments fail
On Fri, 25 Apr 2014 07:38:13 +, Pekka Paunio pekka.pau...@newsbrokers.fi wrote: Folowing procedure update fails apparently because comment contains non us character 'ä'. Goes through without 'ä'. Should this be so? What is your Firebird version, and which connection character set do you use? Mark
RE: [firebird-support] non us characters in comments fail
Yes, and it is running on Win 7 64 bit. Pekka From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Pekka Paunio Sent: 25. huhtikuuta 2014 10:56 To: firebird-support@yahoogroups.com Subject: RE: [firebird-support] non us characters in comments fail Charset is UTF8 and Server version is 2.5.2. Pekka From: firebird-support@yahoogroups.commailto:firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Mark Rotteveel Sent: 25. huhtikuuta 2014 10:51 To: firebird-support@yahoogroups.commailto:firebird-support@yahoogroups.com Subject: Re: [firebird-support] non us characters in comments fail On Fri, 25 Apr 2014 07:38:13 +, Pekka Paunio pekka.pau...@newsbrokers.fimailto:pekka.pau...@newsbrokers.fi wrote: Folowing procedure update fails apparently because comment contains non us character 'ä'. Goes through without 'ä'. Should this be so? What is your Firebird version, and which connection character set do you use? Mark
Re: [firebird-support] non us characters in comments fail
Yes, I had one of these yesterday - part of a comment had been cut-and-pasted from Word, and contained something that looked like an ASCII minus but was in fact an em-rule. Whether you get a failure or not, and at which point of the process, depends, apparently, on all sorts of things, including in particular the connection character set. In our case the procedure had been stored in the database OK, and the application ran OK, but developers couldn't extract metadata from the database using Database Workbench or (to a more limited extent) FlameRobin. I decided that the best way out of it for me was to replace the em-rule with a minus. -- Tim Ward
RE: [firebird-support] non us characters in comments fail
There seems to be all sorts of annoyances that have to do with character sets. For me it is not necessary to use non us characters but these things take time unnecessarily. Pekka From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Tim Ward Sent: 25. huhtikuuta 2014 11:09 To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] non us characters in comments fail Yes, I had one of these yesterday - part of a comment had been cut-and-pasted from Word, and contained something that looked like an ASCII minus but was in fact an em-rule. Whether you get a failure or not, and at which point of the process, depends, apparently, on all sorts of things, including in particular the connection character set. In our case the procedure had been stored in the database OK, and the application ran OK, but developers couldn't extract metadata from the database using Database Workbench or (to a more limited extent) FlameRobin. I decided that the best way out of it for me was to replace the em-rule with a minus. -- Tim Ward
Re: [firebird-support] non us characters in comments fail
On 25/04/2014 09:14, Pekka Paunio wrote: There seems to be all sorts of annoyances that have to do with character sets. For me it is not necessary to use non us characters but these things take time unnecessarily. There is a Cambridge Computer Science exam question: Explain why even experienced programmers have difficulties with character sets. Originally you were expected to write an essay about escape sequences on flexowriter tapes (five bit wide paper tapes); in my day we were expected to write about conversions between ASCII and EBCDIC. I don't know whether the question is still asked with unchanged wording but can see no reason why it shouldn't be! - today's essay might be about something like how to represent Chinese in the from line of an email. -- Tim Ward
Re: [firebird-support] non us characters in comments fail
Hello Tim, Yes, I had one of these yesterday - part of a comment had been cut-and-pasted from Word, and contained something that looked like an ASCII minus but was in fact an em-rule. Whether you get a failure or not, and at which point of the process, depends, apparently, on all sorts of things, including in particular the connection character set. In our case the procedure had been stored in the database OK, and the application ran OK, but developers couldn't extract metadata from the database using Database Workbench or (to a more limited extent) FlameRobin. Are you still experiencing this issue with recent versions of Database Workbench? With regards, Martijn Tonies Upscene Productions http://www.upscene.com Download Database Workbench for Oracle, MS SQL Server, Sybase SQL Anywhere, MySQL, InterBase, NexusDB and Firebird!
Re: [firebird-support] non us characters in comments fail
I'm using v4.4.5.0. I can't check what others are using as they aren't in the office just right now, but I would expect them to be on the same version. On 25/04/2014 09:23, Martijn Tonies (Upscene Productions) wrote: Hello Tim, Yes, I had one of these yesterday - part of a comment had been cut-and-pasted from Word, and contained something that looked like an ASCII minus but was in fact an em-rule. Whether you get a failure or not, and at which point of the process, depends, apparently, on all sorts of things, including in particular the connection character set. In our case the procedure had been stored in the database OK, and the application ran OK, but developers couldn't extract metadata from the database using Database Workbench or (to a more limited extent) FlameRobin. Are you still experiencing this issue with recent versions of Database Workbench? With regards, Martijn Tonies Upscene Productions http://www.upscene.com -- Tim Ward
RE: [firebird-support] non us characters in comments fail
On Fri, 25 Apr 2014 07:55:35 +, Pekka Paunio pekka.pau...@newsbrokers.fi wrote: Charset is UTF8 and Server version is 2.5.2. Is that your *connection* character set or your *database* character set? Also how are you executing this script? It is very easy for a tool to use the connection character set UTF-8, but then send bytes that are - for example - ISO-8859-1 which then leads to transliteration errors as there are byte combinations that are invalid UTF-8. An ä in ISO-8859-1 is byte 228 or 1110 0100 meaning the character consists of 3 bytes, this means this byte must be followed by two bytes with the two highest bits set to 10, however your ä is followed by a space (32 or 0010 ) and an asterisk(*, 42 or 0010 1010) and so it is an invalid UTF-8 character! The same when you connect with connection character set NONE, the client sends the bytes as is and Firebird then tries to store it in UNICODE_FSS of the system table, this fails for the same reasons. Mark
Re: [firebird-support] non us characters in comments fail
Hello Tim, Hmm, if Firebird allows you to store such characters, I would expect Database Workbench to support it. ;) If you can find a reproducible case, let me know. With regards, Martijn Tonies Upscene Productions http://www.upscene.com Download Database Workbench for Oracle, MS SQL Server, Sybase SQL Anywhere, MySQL, InterBase, NexusDB and Firebird! From: Tim Ward Sent: Friday, April 25, 2014 10:27 AM To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] non us characters in comments fail I'm using v4.4.5.0. I can't check what others are using as they aren't in the office just right now, but I would expect them to be on the same version. On 25/04/2014 09:23, Martijn Tonies (Upscene Productions) wrote: Hello Tim, Yes, I had one of these yesterday - part of a comment had been cut-and-pasted from Word, and contained something that looked like an ASCII minus but was in fact an em-rule. Whether you get a failure or not, and at which point of the process, depends, apparently, on all sorts of things, including in particular the connection character set. In our case the procedure had been stored in the database OK, and the application ran OK, but developers couldn't extract metadata from the database using Database Workbench or (to a more limited extent) FlameRobin. Are you still experiencing this issue with recent versions of Database Workbench?
Re: [firebird-support] non us characters in comments fail
This seems to be repeatable: (1) Store the procedure in the database from Database Workbench with connection character set none. (2) You can now read it no problem using the same instance of Database Workbench, but someone else who has Database Workbench's character set UTF8 then gets the transliteration error on trying to read the procedures. It seems to me that (1) is most likely to be the problem - it appears that Database Workbench allowed me to store illegitimate garbage into the database: something should have told me not to or at least warned me that I was being silly? Might not sound like a big deal, but with hundreds of procedures, and the transliteration error message giving not the remotest clue as to what the problem was, it took several of us many hours over several days to find it. On 25/04/2014 09:39, Martijn Tonies (Upscene Productions) wrote: Hello Tim, Hmm, if Firebird allows you to store such characters, I would expect Database Workbench to support it. ;) If you can find a reproducible case, let me know. With regards, Martijn Tonies Upscene Productions http://www.upscene.com Download Database Workbench for Oracle, MS SQL Server, Sybase SQL Anywhere, MySQL, InterBase, NexusDB and Firebird! From: Tim Ward Sent: Friday, April 25, 2014 10:27 AM To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] non us characters in comments fail I'm using v4.4.5.0. I can't check what others are using as they aren't in the office just right now, but I would expect them to be on the same version. On 25/04/2014 09:23, Martijn Tonies (Upscene Productions) wrote: Hello Tim, Yes, I had one of these yesterday - part of a comment had been cut-and-pasted from Word, and contained something that looked like an ASCII minus but was in fact an em-rule. Whether you get a failure or not, and at which point of the process, depends, apparently, on all sorts of things, including in particular the connection character set. In our case the procedure had been stored in the database OK, and the application ran OK, but developers couldn't extract metadata from the database using Database Workbench or (to a more limited extent) FlameRobin. Are you still experiencing this issue with recent versions of Database Workbench? -- Tim Ward
RE: [firebird-support] non us characters in comments fail
You are right. I changed the connection charset to utf-8 and now it accepts non us charsets. Pekka From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Mark Rotteveel Sent: 25. huhtikuuta 2014 11:38 To: firebird-support@yahoogroups.com Subject: RE: [firebird-support] non us characters in comments fail On Fri, 25 Apr 2014 07:55:35 +, Pekka Paunio pekka.pau...@newsbrokers.fimailto:pekka.pau...@newsbrokers.fi wrote: Charset is UTF8 and Server version is 2.5.2. Is that your *connection* character set or your *database* character set? Also how are you executing this script? It is very easy for a tool to use the connection character set UTF-8, but then send bytes that are - for example - ISO-8859-1 which then leads to transliteration errors as there are byte combinations that are invalid UTF-8. An ä in ISO-8859-1 is byte 228 or 1110 0100 meaning the character consists of 3 bytes, this means this byte must be followed by two bytes with the two highest bits set to 10, however your ä is followed by a space (32 or 0010 ) and an asterisk(*, 42 or 0010 1010) and so it is an invalid UTF-8 character! The same when you connect with connection character set NONE, the client sends the bytes as is and Firebird then tries to store it in UNICODE_FSS of the system table, this fails for the same reasons. Mark
[firebird-support] Re: Help with Update using Subquery
Have you tried something like this? UPDATE Table_1 a SET a.Column = 1 WHERE a.PK IN (SELECT b.PK FROM Table_1 b WHERE conditon = criteria)
[firebird-support] Re: Help with Update using Subquery
That did the trick.I was leaving out the a.PK IN portion. Thanks
Re: Odp: [firebird-support] Request for advice
Em 25/4/2014 01:31, liviusliv...@poczta.onet.pl escreveu: Hi, But you also misunderstud advice. Blobs are not stored in table with its other fields. In record exists only blob id and blob is stored on separate pages. Then moving it to separate table do nothing. But i always prefere store big data like document scans outside of database and in main database have only some hint about file name without final location. Only application have knowlage about final location and can load document Regards, Karol Bieniaszewski Nope... If the blob is small enough to fit on the data page with the records it will be stored there. I don't remember the rule exactly, but it is how it works. It reduces dramatically the number of records per page, once the most of the page are used to store the blob content. see you !
[firebird-support] Building from source on both SCO and Solaris
All, I got handed a project to get a v5.5 IB database updated and migrated to Solaris (x86 for dev, T5 LDOM for prod). At this time the plan is to keep it on IB/Firebird but use more modern (supported) platform. First step of the project is to build a new working environment to do the migration development. I have my SCO OpenServer 5.0.7 environment all built and it can compile C/C++ apps with my internal test suite (gcc and gmake and basic libraries). But, I am getting an error during the IB build. I thought I would start out with 1.0.3 since its as close to the v5.5 that we already have on our 5.0.6 system. Then move right into latest release once the UAT is completed. Here is the output of my Configure.sh … Looks like an issue with the ln options and shell script expressions. - Setting build version strings in file jrd/build_no.h - building boot std databases - Setting build version strings in file jrd/build_no.h - Copying boot files into build tree - Setting up the superserver directory structure ln: Insufficient arguments Usage: ln [-fs] source_file target_file ln [-fs] source_file... target_dir ./Configure.sh: oa]: not found …etc… Any help would be appreciated. -M
