New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow the selection of SQL_INT64, SQL_DATE and SQL_TIME in dialect 1 [CORE3972] #4305
Comments
Modified by: @asfernandesstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Alpha 1 [ 10331 ] assignee: Adriano dos Santos Fernandes [ asfernandes ] |
Commented by: Sean Leyne (seanleyne) Since Dialect 1 already has a DATE (which is actually date/time -- ie. TIMESTAMP), how will the DATE type be handled? |
Commented by: @asfernandes If the database was in dialect 3 and a DATE column is created, then database (or client) is switched to dialect 1, that DATE column will be selected as a SQL_DATE type. Previous it raised an error. |
Commented by: Sean Leyne (seanleyne) I was asking, how in Dialect 1, will a user be able to define a new column using the existing DATE (Timestamp) functionality, as well as the Dialect 3 DATE (date only)? Are you suggesting that the new datatypes will only be supported if a database is created as Dialect 3 and then "regressed" to Dialect 1? |
Commented by: @asfernandes The title says "allow the selection", it's what it does. Something (invalid in dialect 1) must already be created. |
Commented by: Sean Leyne (seanleyne) Adriano, "Allow the selection" is not as clear a statement as you think it is. The statement can mean: - Allow SQL statements from Dialect 1 client to refer/use columns defined using SQL_INT64, SQL_DATE and SQL_TIME datatypes |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @asfernandes
As an immediate workaround for CORE3964, I propose to let BIGINT (and DATE and TIME) to be passed for dialect 1 clients.
Thechanges just transform something that is currently an error into something that may be unexpected (SQL_INT64) but will work for good clients.
Arithmetics will not be changed:
-- Create database on dialect 3
isql
create table t1 (n1 numeric(12,3));
insert into t1 values (1.23);
insert into t1 values (10.23);
insert into t1 values (3.567);
commit;
exit;
-- Change database and client to dialect 1 (with new semantics)
gfix -sql_dialect 1 zz.fdb
isql -sql_dialect 1 zz.fdb
set sqlda_display on;
select n1, n1 / 2 from t1;
OUTPUT SQLDA version: 1 sqln: 20 sqld: 2
01: sqltype: 581 INT64 Nullable sqlscale: -3 sqlsubtype: 1 sqllen: 8
: name: (2)N1 alias: (2)N1
: table: (2)T1 owner: (6)SYSDBA
02: sqltype: 481 DOUBLE Nullable sqlscale: 0 sqlsubtype: 0 sqllen: 8
: name: (6)DIVIDE alias: (6)DIVIDE
: table: (0) owner: (0)
===================== =======================
1.230 0.6150000000000000
10.230 5.115000000000000
3.567 1.783500000000000
-- Test with current dialect 1
Statement failed, SQLSTATE = 42S22
Dynamic SQL Error
-SQL error code = -206
-Column unknown
-N1
-Client SQL dialect 1 does not support reference to BIGINT datatype
Commits: c0b11f5
The text was updated successfully, but these errors were encountered: