Subject | Re: [IBO] IBO 4.8.7 to IBO 5.2.0 6 |
---|---|
Author | Robert Martin |
Post date | 2013-06-16T21:08:06Z |
Hi Helen
Thanks. I understand the issues and agree that generally reserved words
should be avoided like the plague. The only fields that are quoted in
our DB are reserved words that were defined before the database was a
Firebird database !
All our SQL is correct and working, the database version has not
changed, the issue is with IBO. Previously (IBO 4.8) code like
Query.FieldByName('Rows').AsInteger
worked perfectly. Now this code returns a 'Field not found' exception
(IBO 5.2). This is obviously a code change between IBO versions and I
was hoping that Jason would be able to help me out with this.
Cheers
Rob
Thanks. I understand the issues and agree that generally reserved words
should be avoided like the plague. The only fields that are quoted in
our DB are reserved words that were defined before the database was a
Firebird database !
All our SQL is correct and working, the database version has not
changed, the issue is with IBO. Previously (IBO 4.8) code like
Query.FieldByName('Rows').AsInteger
worked perfectly. Now this code returns a 'Field not found' exception
(IBO 5.2). This is obviously a code change between IBO versions and I
was hoping that Jason would be able to help me out with this.
Cheers
Rob
On 14/06/2013 1:06 p.m., Helen Borrie wrote:
> At 10:22 a.m. 14/06/2013, IBO Support List wrote:
>> When you put a name inside of double quotes then it becomes case sensitive.
> Yes, I would *not* recommend defining columns that use quoted keywords as case-sensitive. Define them in upper case and, in some conditions, they will work if used unquoted.
>
> I have noticed that IB_SQL, for some longish time, is automatically double-quoting some identifiers in a database of mine that started life as ODS 10.1, where the names were not keywords. I have never figured out whether that is just a trick of IB_SQL or whether it is actually happening in the IB_Statement processing. Because these identifiers are defined in upper case, it causes no problems whatsoever.
>
> And no, don't use column aliases for real columns unless you have *no other choice*. They are not intended for that usage and they'll kill performance. It's a bit of a bind to have to go back and fix up those double-quoted columns but it's a do-once and once it's done, it's done for good.
>
> Helen
>
>
>