Subject | Re: [firebird-support] Re: Using reserve words in queries |
---|---|
Author | Helen Borrie |
Post date | 2005-03-02T02:21:37Z |
At 01:36 AM 2/03/2005 +0000, you wrote:
creating dialect 3 databases by default. Quoted identifers are valid in
dialect 3 databases.
If you used FlameRobin instead of isql to create your database, and got a
dialect database by default, then you should inform the FR
developers. This is just an alpha version of the tool!! I currently have
Alpha 2, which can't create databases at all, because of a quoting bug in
the program, but it's interface certainly shows that it would create a
dialect 3 database.
You can change the dialect of a database, using
gfix -sq 3 <db-path> -u sysdba -pas xyxyxyxy
But all that does is to change the dialect attribute and make the dialect 3
language features available for future work. It does NOT convert existing
data or data types or constraint calculations or recompile your PSQL
modules. BIG TROUBLE!! Most people have abandoned this as a way to
"convert" - since it is an illusion.
Simply, the best, safest thing to do is to extract your metadata, recreate
your database from it as dialect 3 and then pump the data.
Before going to this trouble, though, run a gstat -h on the database just
to be sure that you really do have this problem. May I also suggest that
you treat yourself as a field-tester for FlameRobin and NOT try to use it
to do things with databases that matter?
How could the 1.5.2 version of isql create a dialect 1 database, apparently
by default? well, here's how it could have happened. You open an isql
session over a dialect 1 database - for example, employee.gdb that ships
with Firebird 1.0 and all of the Borland tools (up to and including the
latest versions of InterBase and Delphi). Isql detects that it is
connecting to a dialect 1 database and sets the client dialect to 1. After
fiddling about with this dialect 1 database, you decide to create a new
database. If you don't use a SET SQL DIALECT 3 command in isql before
creating this new database, it will be a dialect 1 database !! (unless you
actually ran a script that included that command...)
./heLen
> >Yes, dialect 3 is the native dialect of Firebird and isql should be
> > The Langref is correct. However, if your database is Dialect 1,
>you won't
> > be able to use reserved words as identifiers AT ALL.
> >
> > What tool are you using to create the database?
> >
> > ./heLen
>
>
>I've tried my SQL script with ISQL that came with firebird and
>FlameRobin v0.2.0. According to FlameRobin's "About", it is using
>IBPP library version 2.3.4.0 and wxWidgets library version 2.5.3.
>
>I misinterpreted the FAQ about quoted identifiers and the various
>dialects at http://www.firebirdsql.org/index.php?op=faq#q0000.dat.
>
>Would one of the other dialects allow me to use a reserved word, and
>if so, is it possible to change the dialect?
creating dialect 3 databases by default. Quoted identifers are valid in
dialect 3 databases.
If you used FlameRobin instead of isql to create your database, and got a
dialect database by default, then you should inform the FR
developers. This is just an alpha version of the tool!! I currently have
Alpha 2, which can't create databases at all, because of a quoting bug in
the program, but it's interface certainly shows that it would create a
dialect 3 database.
You can change the dialect of a database, using
gfix -sq 3 <db-path> -u sysdba -pas xyxyxyxy
But all that does is to change the dialect attribute and make the dialect 3
language features available for future work. It does NOT convert existing
data or data types or constraint calculations or recompile your PSQL
modules. BIG TROUBLE!! Most people have abandoned this as a way to
"convert" - since it is an illusion.
Simply, the best, safest thing to do is to extract your metadata, recreate
your database from it as dialect 3 and then pump the data.
Before going to this trouble, though, run a gstat -h on the database just
to be sure that you really do have this problem. May I also suggest that
you treat yourself as a field-tester for FlameRobin and NOT try to use it
to do things with databases that matter?
How could the 1.5.2 version of isql create a dialect 1 database, apparently
by default? well, here's how it could have happened. You open an isql
session over a dialect 1 database - for example, employee.gdb that ships
with Firebird 1.0 and all of the Borland tools (up to and including the
latest versions of InterBase and Delphi). Isql detects that it is
connecting to a dialect 1 database and sets the client dialect to 1. After
fiddling about with this dialect 1 database, you decide to create a new
database. If you don't use a SET SQL DIALECT 3 command in isql before
creating this new database, it will be a dialect 1 database !! (unless you
actually ran a script that included that command...)
./heLen