From: Claudio V. C. <cv...@us...> - 2001-06-27 02:19:38
|
Hello, I had the idea that someone has changed code to stop bug [ #412417 ] altering from CHAR to VARCHAR but today I did the following sequence as directed by the bug report: SQL> CREATE TABLE TEST( N CHAR(40)); SQL> ALTER TABLE TEST ALTER N TYPE VARCHAR(40); SQL> commit; SQL> show table test; N VARCHAR(40) Nullable SQL> select rdb$field_source from rdb$relation_fields where rdb$relation_name = 'TEST' and rdb$field _name='N'; RDB$FIELD_SOURCE =============================== RDB$61 SQL> select rdb$field_length, rdb$character_length from rdb$fields where rdb$field_name='RDB$61'; RDB$FIELD_LENGTH RDB$CHARACTER_LENGTH ================ ==================== 42 40 Ouch! What else can I say? Or is it just me? C. --------- Claudio Valderrama C. Ingeniero en Informática - Consultor independiente http://www.cvalde.com - http://firebird.sf.net |
From: Claudio V. C. <cv...@us...> - 2001-06-29 08:48:19
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Claudio > Valderrama C. > Sent: Martes 26 de Junio de 2001 22:20 > > Hello, I had the idea that someone has changed code to stop bug > [ #412417 ] altering from CHAR to VARCHAR > but today I did the following sequence as directed by the bug report: > > SQL> CREATE TABLE TEST( N CHAR(40)); > SQL> ALTER TABLE TEST ALTER N TYPE VARCHAR(40); > SQL> commit; > SQL> show table test; > N VARCHAR(40) Nullable > SQL> select rdb$field_source from rdb$relation_fields where > rdb$relation_name = 'TEST' and rdb$field > _name='N'; > > RDB$FIELD_SOURCE > =============================== > RDB$61 > > SQL> select rdb$field_length, rdb$character_length from rdb$fields where > rdb$field_name='RDB$61'; > > RDB$FIELD_LENGTH RDB$CHARACTER_LENGTH > ================ ==================== > 42 40 > > Ouch! What else can I say? Or is it just me? It turns out to be a bug still present. I think I closed it for now. It was no joy. Really, dyn_mod should be called pandora_box.e instead. At first glance I thought I had solved it, then I tested and found the problem worse. A second try gave the same results. Hence I had to find a way to verify the length of the fields. At one time, I discovered that a field I specified as varchar(10) was going to be stored as rdb$field_length=14 since DSC_make_descriptor had been called twice and its counterpart DSC_streing_length zero times. To put a sentry, I created dyn_fld's dyn_charbytelen member. I tested modifications from domain to domain, field based on built-in type to field based on built-in type and to field based on domain and viceversa, from char to varchar and vice-versa, etc. Hope I didn't create another bug in compensation. C. |
From: Frank Schlottmann-G. <sch...@t-...> - 2001-06-29 12:36:03
|
"Claudio Valderrama C." wrote: > > It turns out to be a bug still present. I think I closed it for now. It was > no joy. Really, dyn_mod should be called pandora_box.e instead. At first > glance I thought I had solved it, then I tested and found the problem worse. > A second try gave the same results. Hence I had to find a way to verify the > length of the fields. At one time, I discovered that a field I specified as > varchar(10) was going to be stored as rdb$field_length=14 since > DSC_make_descriptor had been called twice and its counterpart > DSC_streing_length zero times. To put a sentry, I created dyn_fld's > dyn_charbytelen member. > > I tested modifications from domain to domain, field based on built-in type > to field based on built-in type and to field based on domain and viceversa, > from char to varchar and vice-versa, etc. Hope I didn't create another bug > in compensation. Sorry to disturb you, but there is sth. that may (or may not) be related to this stuff: create procedure cast6(a varchar(10)) RETURNS (b date) as begin b = a; SUSPEND; end ^ SQL> execute procedure cast6 '12-Mar-92'; Statement failed, SQLCODE = -802 arithmetic exception, numeric overflow, or string truncation SQL> execute procedure cast6 '12-Mar92'; B =========== 1992-03-12 SQL> So this procedure in fact accepts only a varchar(8). There is this suspicious blr_varying2,0,0,8,0 in RDB$PROCEDURE_BLR I don't know when this bug was introduced, as it is some time ago since my last TCS runs. There is another failure in CF_ISQL_14 where create table t5 (af computed by (1+2)); insert into t5 values(10); will fail with > Statement failed, SQLCODE = -804 > > Dynamic SQL Error > -SQL error code = -804 > -Count of columns does not equal count of values > instead of < Statement failed, SQLCODE = -151 < < attempted update of read-only column Frank -- "Fascinating creatures, phoenixes. They can carry immensely heavy loads, their tears have healing powers and they make highly faithful pets." - J.K. Rowling http://firebirdsql.org |
From: Frank Schlottmann-G. <sch...@t-...> - 2001-06-29 16:04:48
|
Hi Claudio, I have done some more tests > > > There is this suspicious > > blr_varying2,0,0,8,0 > > in RDB$PROCEDURE_BLR > > I don't know when this bug was introduced, as it is some time ago since > my last > TCS runs. This one is from your last checkin, it fails only for build_num > 242 > There is another failure in CF_ISQL_14 where > > create table t5 (af computed by (1+2)); > insert into t5 values(10); > > will fail with > > Statement failed, SQLCODE = -804 > > > > Dynamic SQL Error > > -SQL error code = -804 > > -Count of columns does not equal count of values > > > > instead of > > < Statement failed, SQLCODE = -151 > < > < attempted update of read-only column This one fails from build_no >= 238 so it seems to be from the stuff you checked in on Tuesday. Frank -- "Fascinating creatures, phoenixes. They can carry immensely heavy loads, their tears have healing powers and they make highly faithful pets." - J.K. Rowling http://firebirdsql.org |
From: Claudio V. C. <cv...@us...> - 2001-06-30 22:21:29
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Frank > Schlottmann-Goedde > Sent: Viernes 29 de Junio de 2001 12:04 > To: fir...@li... > > > There is another failure in CF_ISQL_14 where > > > > create table t5 (af computed by (1+2)); > > insert into t5 values(10); > > > > will fail with > > > Statement failed, SQLCODE = -804 > > > > > > Dynamic SQL Error > > > -SQL error code = -804 > > > -Count of columns does not equal count of values > > > > > > > instead of > > > > < Statement failed, SQLCODE = -151 > > < > > < attempted update of read-only column Some weeks ago, the firebird queen (the same that shared dolls with Ada Lovelace in her infancy <g>) asked me to provide a modification to allow the following to happen: create table tc(a int, b computed (a + 1)); commit; insert into tc values(a); In few words, for lazy people, to allow them insert in a table without writing the list of fields EVEN THOUGH the table has computed fields, that will be ignored. Now, you come with the paroxysm of the test cases, emulating a fool that wants to insert a value in the unique and read-only field of the table. Well, I have two suggestions: - Is there any damage if I add a SHORT or USHORT to the struct req is dsql.h? I think SSHORT is enough since the limit of field count in a table is 32767. This field, called req_computed_fcount would be augmented in define_insert_action(), so instead of my code if (field->fld_flags & FLD_computed) continue; it will be if (field->fld_flags & FLD_computed) { ++request->req_computed_fcount; continue; } hence by the time an error condition is detected: if request->req_computed_fcount is > 0 then the message Ann wants is shown else the traditional message Frank loves is shown. Flames, diatribes, flack? Anyway, do I need to create a new error message, Ann? I never have seen the one you describe. C. |
From: Frank Schlottmann-G. <sch...@t-...> - 2001-07-01 08:39:12
|
"Claudio Valderrama C." wrote: > hence by the time an error condition is detected: > if request->req_computed_fcount is > 0 > then the message Ann wants is shown > else the traditional message Frank loves is shown. > > Flames, diatribes, flack? > Anyway, do I need to create a new error message, Ann? I never have seen the > one you describe. I have changed the error message and the test to follow the new behavior. Frank -- "Fascinating creatures, phoenixes. They can carry immensely heavy loads, their tears have healing powers and they make highly faithful pets." - J.K. Rowling http://firebirdsql.org |
From: Frank Schlottmann-G. <sch...@t-...> - 2001-07-01 11:54:17
|
"Claudio Valderrama C." wrote: > > In few words, for lazy people, to allow them insert in a table without > writing the list of fields EVEN THOUGH the table has computed fields, that > will be ignored. Now, you come with the paroxysm of the test cases, > emulating a fool that wants to insert a value in the unique and read-only > field of the table. These annoying QA people :-) I just dont like failures in the TCS. > Well, I have two suggestions: > - Is there any damage if I add a SHORT or USHORT to the struct req is > dsql.h? I think SSHORT is enough since the limit of field count in a table > is 32767. This field, called > req_computed_fcount > would be augmented in define_insert_action(), so instead of my code > if (field->fld_flags & FLD_computed) > continue; > it will be > if (field->fld_flags & FLD_computed) > { > ++request->req_computed_fcount; > continue; > } > hence by the time an error condition is detected: > if request->req_computed_fcount is > 0 > then the message Ann wants is shown > else the traditional message Frank loves is shown. I don't think that this is necessary. It is ok as it is now. The message that Ann proposed is good for both cases. Frank -- "Fascinating creatures, phoenixes. They can carry immensely heavy loads, their tears have healing powers and they make highly faithful pets." - J.K. Rowling http://firebirdsql.org |
From: Ann W. H. <aha...@ib...> - 2001-06-29 18:35:53
|
At 02:34 PM 6/29/2001 +0200, Frank Schlottmann-Goedde wrote: >There is another failure in CF_ISQL_14 where > > create table t5 (af computed by (1+2)); > insert into t5 values(10); > >will fail with > > -Count of columns does not equal count of values > > >instead of > >< Statement failed, SQLCODE = -151 >< >< attempted update of read-only column This one is interesting - at least sort of interesting. In the released version, you must always supply a target field list for any insert to a table that includes a computed field. create table t1 (f1 integer, f2 integer, f3 integer f4 computed by (f1 + f2 + f3 + f4); insert into t1 values (1, 2, 3) > > Error: Count of columns does not equal count of values insert into t1 values (1, 2, 3, 4) > Error: attempted update of read-only column I suggested that for the case of an implicit target list we should not count read-only fields. That's where the change came from. My inclination is to change the message to Count of read-write columns does not equal count of values and reinitialize the test. Regards, Ann www.ibphoenix.com We have answers. |
From: Claudio V. C. <cv...@us...> - 2001-06-30 03:08:00
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Frank > Schlottmann-Goedde > Sent: Viernes 29 de Junio de 2001 8:34 > > create procedure cast6(a varchar(10)) RETURNS (b date) as > begin > b = a; > SUSPEND; > end > ^ > > SQL> execute procedure cast6 '12-Mar-92'; Frank, I assume you know that SUSPEND is meant to be used when you do a SELECT from a proc and not when you call EXECUTE, right? > Statement failed, SQLCODE = -802 > > arithmetic exception, numeric overflow, or string truncation > > So this procedure in fact accepts only a varchar(8). > > There is this suspicious > > blr_varying2,0,0,8,0 > in RDB$PROCEDURE_BLR It's easy to see why: we are piggybacking a couple of shitty routines that are inconsistent. I fixed the path for tables, BUT... DDL.C-define_procedure() calls MAKE.C-MAKE_variable() that in turns calls MAKE_desc_from_field() As a good MAKE_desc* I would expect the latter to increment the field in SIZEOF(UCHAR) if it's varchar, but it DOESN'T. So I've found the cause for the comment I wrote yesterday in a source file: "I don't understand why the length is incremented here to be decremented later". Whoever wrote that code was trying to get around bad designed functions or at least trickily designed functions. MAKE_variable is called three times from DDL.C... only God knows what will happen if I fix another thing instead. Since it's not called from other place, I could pass it a last parameter, a flag telling it whether to adjust varchars or not. The other alternative is to undo my changes to DDL (where I didn't allow the increment to happen for varchar) and pray for the sentry I added to dyn_fld struct to catch possible cases in DYN_MOD where rdb$field_length could go out of sync. I cannot fix MAKE_desc_from_field since it's used in other places and works well as it is, without adjusting the length. C. |
From: Frank Schlottmann-G. <sch...@t-...> - 2001-06-30 05:32:14
|
"Claudio Valderrama C." wrote: > > > -----Original Message----- > > From: fir...@li... > > [mailto:fir...@li...]On Behalf Of Frank > > Schlottmann-Goedde > > Sent: Viernes 29 de Junio de 2001 8:34 > > > > create procedure cast6(a varchar(10)) RETURNS (b date) as > > begin > > b = a; > > SUSPEND; > > end > > ^ > > > > SQL> execute procedure cast6 '12-Mar-92'; > > Frank, I assume you know that SUSPEND is meant to be used when you do a > SELECT from a proc and not when you call EXECUTE, right? I know, but I didn't design these tests. > > > Statement failed, SQLCODE = -802 > > > > arithmetic exception, numeric overflow, or string truncation > > > > So this procedure in fact accepts only a varchar(8). > > > > There is this suspicious > > > > blr_varying2,0,0,8,0 > > in RDB$PROCEDURE_BLR > > It's easy to see why: we are piggybacking a couple of shitty routines that > are inconsistent. I fixed the path for tables, BUT... > DDL.C-define_procedure() calls > MAKE.C-MAKE_variable() that in turns calls > MAKE_desc_from_field() > > As a good MAKE_desc* I would expect the latter to increment the field in > SIZEOF(UCHAR) if it's varchar, but it DOESN'T. So I've found the cause for > the comment I wrote yesterday in a source file: "I don't understand why the > length is incremented here to be decremented later". Whoever wrote that code > was trying to get around bad designed functions or at least trickily > designed functions. So I hope you will be successfull at last. I tried yesterday to find out what was going wrong there, but I gave up and will leave it to you :-) Frank -- "Fascinating creatures, phoenixes. They can carry immensely heavy loads, their tears have healing powers and they make highly faithful pets." - J.K. Rowling http://firebirdsql.org |
From: Ann W. H. <aha...@ib...> - 2001-07-02 02:07:51
|
> >As a good MAKE_desc* I would expect the latter to increment the field in >SIZEOF(UCHAR) if it's varchar, but it DOESN'T. It wouldn't surprise me at all to find different conventions in DSQL than in the engine. MAKE_variable should increment the size of varchars by two because it's getting its length from the user declaration, which is the string length. Regards, Ann www.ibphoenix.com We have answers. |