FirebirdSQL
ibase_prepare fails to find table with SQL that has double quotes on table identifiers
Environment arm64 linux debian 11 (testing) environment. Interbase 3.0 installed, because 4.0 wasn't available until recently.
the php-firebird driver function ibase_prepare , rejects the SQL statement INSERT INTO "test" . . . The table name "test" exists, but the error returned is that table test cannot be found.
--- fbird_prepare(): Dynamic SQL Error SQL error code = -204 Table unknown test At line 1, column 13 ----
"test" is a double - quoted identifier. But in the same PHP and database environment, using the pdo_firebird driver access, with the same connect string, the prepare call using same SQL is successful.
I note that both drivers seem to use client libraries and similar api to access. eg .. isc_dsql_sql_info Maybe this is something to do with different automatic dialect allocation on connection.
Can you try this: INSERT INTO "TEST" . . .
Firebird internally use uppercases. I'm sure there is no table "test" but "TEST". Please check and give me feedback.
Firebird internally use uppercases. I'm sure there is no table "test" but "TEST". Please check and give me feedback.
That is only true for unquoted identifiers. If the table was created as create table "test" ..., the name in the metadata is test, not TEST.
Are you sure this is a bug? Look at isql behavior:
SQL> select count(*) from COUNTRY;
COUNT
===================== 0 not quoted - table found
SQL> select count(*) from "COUNTRY";
COUNT
===================== 0 quoted uppercase - table found
SQL> select count(*) from "country"; Statement failed, SQLSTATE = 42S02 Dynamic SQL Error -SQL error code = -204 -Table unknown -country -At line 1, column 22 SQL> quoted lowercase - table not found, and that's not a bug, that's SQL feature
@AlexPeshkoff
You're right. Using the code
select count(*) from "COUNTRY";
no error is thrown.
So this is really not a bug as Alex said. If you use quotes, then you still have to use quotes in the query. You also have to match the case you created the table.
I get the feeling there is now some confusion about what the actual problem is. How I read the OP, is that the query insert into "test" ... fails, while they do have a table "test" (i.e. case-sensitive). I guess a minimal, reproducible example is needed to confirm what the actual problem is.