Menu
▾
▴
firebird-devel
|
From: Jason W. (JIRA) <tr...@fi...> - 2011-04-26 07:45:28
|
Query STARTING WITH :Param returns inconsistent result depending upon ORDER BY clause
-------------------------------------------------------------------------------------
Key: CORE-3452
URL: http://tracker.firebirdsql.org/browse/CORE-3452
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.1.4, 2.5.0, 1.5.6, 2.1.3, 2.1.2
Environment: Using IB Objects on a Win XP machine, thus 32 bit.
Reporter: Jason Wharton
I have a query that is shown in the SQL trace below that has an inconsistent behavior depending upon what the sort order of the query is.
The problem seems to have to do with the STARTING WITH clause when used with an input parameter. When the input is a blank string sometimes you get no records and other times you get all records (that aren't null). This material can be easily examined via IB Objects because this is one of the sample applications that comes with the product. I'd be happy to furnish a copy of it for testing purposes to anyone working on this issue.
Here are the tables I'm working with:
CREATE TABLE DESCRIPTION (
ID INTEGER NOT NULL
, DBID INTEGER DEFAULT 1 NOT NULL
, DESCRIPTION VARCHAR( 50 ) NOT NULL
, C_CODE VARCHAR( 8 ) DEFAULT '' NOT NULL
, C_DESC VARCHAR( 50 ) DEFAULT '' NOT NULL
, CONSTRAINT PK_DESCRIPTION
PRIMARY KEY ( ID )
)
CREATE TABLE ITEM (
ID INTEGER NOT NULL
, DBID INTEGER DEFAULT 1 NOT NULL
, ASSETNO VARCHAR( 20 ) DEFAULT NULL
, SCANCODE VARCHAR( 20 ) DEFAULT '+' NOT NULL
, SERIALNO VARCHAR( 20 ) DEFAULT NULL
, C_HOSTSCAN VARCHAR( 20 ) DEFAULT NULL
, ID_DESCRIPTION INTEGER DEFAULT 1 NOT NULL
, CONSTRAINT PK_ITEM
PRIMARY KEY ( DBID, ID )
)
ALTER TABLE ITEM
ADD CONSTRAINT RI_ITEM_DESCRIPTION
FOREIGN KEY ( ID_DESCRIPTION )
REFERENCES DESCRIPTION ( ID )
Here is the base statement that returned results:
SELECT ITEM.ID, ITEM.DBID
FROM ITEM, DESCRIPTION
WHERE DESCRIPTION.ID=ITEM.ID_DESCRIPTION
AND ITEM.DBID = ? /* P_DBID */
AND ITEM.ASSETNO STARTING WITH ? /* P_SEARCH */
AND ( ITEM.C_HOSTSCAN >= ? /* OLNK_C_HOSTSCAN */ )
ORDER BY ITEM.C_HOSTSCAN ASC
PLAN SORT (JOIN (ITEM INDEX (IX_ITEM_C_HOSTSCAN), DESCRIPTION INDEX (PK_DESCRIPTION)))
Here are examples of a query that didn't return results:
SELECT ITEM.ID, ITEM.DBID
FROM ITEM, DESCRIPTION
WHERE DESCRIPTION.ID=ITEM.ID_DESCRIPTION
AND ITEM.DBID = ? /* P_DBID */
AND ITEM.ASSETNO STARTING WITH ? /* P_SEARCH */
AND ( ITEM.SCANCODE >= ? /* OLNK_SCANCODE */ )
ORDER BY ITEM.SCANCODE ASC
PLAN SORT (JOIN (ITEM INDEX (IX_ITEM_ASSETNO), DESCRIPTION INDEX (PK_DESCRIPTION)))
SELECT ITEM.ID, ITEM.DBID
FROM ITEM, DESCRIPTION
WHERE DESCRIPTION.ID=ITEM.ID_DESCRIPTION
AND ITEM.DBID = ? /* P_DBID */
AND ITEM.ASSETNO STARTING WITH ? /* P_SEARCH */
AND ( DESCRIPTION.DESCRIPTION >= ? /* OLNK_DESCRIPTION */ )
ORDER BY DESCRIPTION.C_CODE ASC
PLAN SORT (JOIN (ITEM INDEX (IX_ITEM_ASSETNO), DESCRIPTION INDEX (PK_DESCRIPTION)))
SELECT ITEM.ID, ITEM.DBID
FROM ITEM, DESCRIPTION
WHERE DESCRIPTION.ID=ITEM.ID_DESCRIPTION
AND ITEM.DBID = ? /* P_DBID */
AND ITEM.ASSETNO STARTING WITH ? /* P_SEARCH */
AND ( DESCRIPTION.C_CODE >= ? /* OLNK_C_CODE */ )
ORDER BY DESCRIPTION.C_DESC ASC
PLAN SORT (JOIN (ITEM INDEX (IX_ITEM_ASSETNO), DESCRIPTION INDEX (PK_DESCRIPTION)))
Here is a little more detail showing the trace results.
----------------------------------------------------------
This query has a blank string for the parameter and it returns no records.
----------------------------------------------------------
/*---
PREPARE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 2
SELECT ITEM.ID, ITEM.DBID
FROM ITEM, DESCRIPTION
WHERE DESCRIPTION.ID=ITEM.ID_DESCRIPTION
AND ITEM.DBID = ? /* P_DBID */
AND ITEM.ASSETNO STARTING WITH ? /* P_SEARCH */ AND ( DESCRIPTION.DESCRIPTION >= ? /* OLNK_DESCRIPTION */ ) ORDER BY DESCRIPTION.C_CODE ASC
PLAN SORT (JOIN (ITEM INDEX (IX_ITEM_ASSETNO), DESCRIPTION INDEX
(PK_DESCRIPTION)))
FIELDS = [ Version 1 SQLd 2 SQLn 30
ITEM.ID = <NIL>
ITEM.DBID = <NIL> ]
----*/
/*---
DESCRIBE INPUT
STMT_HANDLE = 2
PARAMS = [ Version 1 SQLd 3 SQLn 3
< SQLType: 496 SQLLen: 4 > = <NIL>
< SQLType: 449 SQLLen: 20 > = <NIL>
< SQLType: 448 SQLLen: 50 > = <NIL> ]
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 2
PARAMS = [ Version 1 SQLd 3 SQLn 3
[P_DBID] = 1
[P_SEARCH] = ''
[OLNK_DESCRIPTION] = '' ]
----*/
/*---
OPEN CURSOR
STMT_HANDLE = 2
NAME = C1218089689013596
----*/
/*---
FETCH
STMT_HANDLE = 2
FIELDS = [ Version 1 SQLd 2 SQLn 2
ITEM.ID = 0
ITEM.DBID = 0 ]
ERRCODE = 100
----*/
/*---
CLOSE CURSOR
STMT_HANDLE = 2
----*/
----------------------------------------------------------
This query has a blank string for the parameter, but it returned records.
----------------------------------------------------------
/*---
PREPARE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 2
SELECT ITEM.ID, ITEM.DBID
FROM ITEM, DESCRIPTION
WHERE DESCRIPTION.ID=ITEM.ID_DESCRIPTION
AND ITEM.DBID = ? /* P_DBID */
AND ITEM.ASSETNO STARTING WITH ? /* P_SEARCH */ AND ( ITEM.ASSETNO >= ? /* OLNK_ASSETNO */ ) ORDER BY ITEM.ASSETNO ASC
PLAN SORT (JOIN (ITEM INDEX (IX_ITEM_ASSETNO), DESCRIPTION INDEX
(PK_DESCRIPTION)))
FIELDS = [ Version 1 SQLd 2 SQLn 30
ITEM.ID = <NIL>
ITEM.DBID = <NIL> ]
----*/
/*---
DESCRIBE INPUT
STMT_HANDLE = 2
PARAMS = [ Version 1 SQLd 3 SQLn 3
< SQLType: 496 SQLLen: 4 > = <NIL>
< SQLType: 449 SQLLen: 20 > = <NIL>
< SQLType: 449 SQLLen: 20 > = <NIL> ]
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 2
PARAMS = [ Version 1 SQLd 3 SQLn 3
[P_DBID] = 1
[P_SEARCH] = ''
[OLNK_ASSETNO] = '' ]
SECONDS = 0.016
----*/
/*---
OPEN CURSOR
STMT_HANDLE = 2
NAME = C1218089689013596
----*/
/*---
FETCH
STMT_HANDLE = 2
FIELDS = [ Version 1 SQLd 2 SQLn 2
ITEM.ID = 1001
ITEM.DBID = 1 ]
----*/
000000000000 Lots of fetches removed 00000000000000
/*---
FETCH
STMT_HANDLE = 2
FIELDS = [ Version 1 SQLd 2 SQLn 2
ITEM.ID = 1001
ITEM.DBID = 1 ]
ERRCODE = 100
----*/
/*---
CLOSE CURSOR
STMT_HANDLE = 2
----*/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Support L. <sup...@ib...> - 2011-04-27 22:58:17
|
I am doing a new major release of IB Objects soon and I want to get confirmation of some things before I finalize it. I have some scenarios that I would like to know what to do about. There are a total of 9 possible combinations of 3 aspects. Aspect #1: Database created with a default character set of ??? or NONE. Aspect #2: Database connected to with a character set of ??? or NONE. Aspect #3: Columns given their own character set of ??? or left blank. I need to know what happens with each possible combination. For example, if I have a database that was created with default character set of NONE and there is a column in it defined as UTF8. Then, when I connect to the database using character set of UTF8, how will the data be sent to the client? Will all of it be transliterated into UTF8? Have there been any changes in how this has been handled from version to version? Thanks for helping me get confirmation on this, as well as any additional tidbits you may wish to share. Thanks, Jason LeRoy Wharton www.ibobjects.com |
|
From: Support L. <sup...@ib...> - 2011-04-28 04:24:14
|
I am having trouble with this API call. It seems to work, but also there seems to be something faulty in the way this handles memory because after I return from calling this I get AV's. I have been looking through the sources and I do see some kind of suspicious comments suggesting uncertainty if this is even a valid API call to start with. I can assure that this API call fulfills a unique and beneficial role so I would like to see this get to a point where it works solid and stable. I plan to continue tracing through the sources to see if I can find the culprit of the problem. Also, one a few occasions, I noticed some garbage that got into my result buffer. So, it seems that something is writing to memory where it shouldn't when this call is made. Is there someone I can work with to root this problem out? Thanks, Jason LeRoy Wharton www.ibobjects.com |
|
From: Jason W. <ja...@jw...> - 2011-04-28 05:10:56
|
As an additional note, I believe it could have something to do with the fact that the input parameters are nil and the output parameters are assigned. I'm going to try and see if passing in a dummy input parameter will help to provide a workaround. I say this because elsewhere I use this without any problems and I am passing in both input and output structures. Thanks, Jason LeRoy Wharton www.ibobjects.com |
|
From: Support L. <sup...@ib...> - 2011-04-28 05:05:26
|
I took a closer look and I think I found the culprit on my side of things.
I am using the column type SQL_VARCHAR and so I was not setting the sqllen
figure to match my buffer and take into account the two bytes for the
length. Thus, two bytes were possibly being mangled. Once I made the
adjustment noted below in my code it began to work properly.
Here is my code:
function GetDefaultCharSet( Cn: TIB_Connection;
Tr: TIB_Transaction ): string;
var
POut_DA: PXSQLDA;
nullind: smallint;
tmpName: array[1..255] of byte;
tmpLen: integer;
tmpBytes: RawByteString;
tmpDSQL: TIB_DSQL;
begin
Result := '';
if Assigned( cn ) and Cn.Connected then
begin
if not Assigned( Tr ) then
Tr := Cn.SchemaCache.Transaction;
tmpDSQL := TIB_DSQL.Create( cn );
try
tmpDSQL.RetrieveDomainNames := false;
tmpDSQL.IB_Connection := Cn;
tmpDSQL.IB_Transaction := Tr;
tmpDSQL.CheckTransaction( true, tmReadRecord );
GetMem( POut_DA, XSQLDA_LENGTH( 1 ));
try
with POut_DA^ do
begin
version := SQLDA_VERSION1;
sqln := 1;
sqld := 1;
with sqlvar[ 0 ] do
begin
sqltype := SQL_VARYING;
// I need to subtract two bytes from sqllen to make
// room for the length indicator.
sqllen := SizeOf( tmpName ) - 2; //!!!!!!!!
sqldata := @tmpName;
sqlscale := 0;
sqlind := @nullind;
relname_length := 0;
sqlname_length := 0;
aliasname_length := 0;
ownname_length := 0;
end;
end;
tmpDSQL.ExecImmed2( 'SELECT D.RDB$CHARACTER_SET_NAME ' +
'FROM RDB$DATABASE D', nil, POut_DA );
with SQL_VARCHAR( pointer( @tmpName )^ ) do
begin
tmpLen := vary_len_low + vary_len_high * 256;
SetLength( tmpBytes, tmpLen );
Move( vary_string, tmpBytes[1], tmpLen );
end;
Result := Trim( iboDecodeA( tmpBytes ) {Don't put CharSet here.} );
finally
FreeMem( POut_DA );
if Assigned( Tr ) then
Tr.CheckOat;
end;
finally
tmpDSQL.Free;
end;
end;
end;
Thanks,
Jason LeRoy Wharton
www.ibobjects.com
|
|
From: Dimitry S. <sd...@ib...> - 2011-05-23 09:01:58
|
28.04.2011 6:43, Jason Wharton wrote: > I say this because elsewhere I use this without any problems and I am > passing in both input and output structures. You must be very lucky if you never encountered CORE-3202. -- SY, SD. |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-04-28 10:41:41
|
On 27/04/2011 19:28, Support List wrote: > I am doing a new major release of IB Objects soon and I want to get > confirmation of some things before I finalize it. > > I have some scenarios that I would like to know what to do about. > There are a total of 9 possible combinations of 3 aspects. > > Aspect #1: Database created with a default character set of ??? or NONE. > Aspect #2: Database connected to with a character set of ??? or NONE. > Aspect #3: Columns given their own character set of ??? or left blank. > > I need to know what happens with each possible combination. > > For example, if I have a database that was created with default character > set of NONE and there is a column in it defined as UTF8. Then, when I > connect to the database using character set of UTF8, how will the data be > sent to the client? Will all of it be transliterated into UTF8? > Database charset is used only for one purpose: default character set in DDL commands. > Have there been any changes in how this has been handled from version to > version? > Probably some inconsistency here and there, but general idea is the same since 1.5. Data is transliterated from its charset to client charset and vice-versa. NONE/OCTETS -> something: data is validated accordingly to something something -> NONE/OCTETS: nothing is done something1 -> something2: data is transliterated Adriano |
|
From: Geoff W. <ge...@te...> - 2011-04-28 11:20:34
|
Adriano dos Santos Fernandes wrote: ... > Data is transliterated from its charset to client charset and > vice-versa. NONE/OCTETS ->> something: data is validated accordingly to something something ->> NONE/OCTETS: nothing is done something1 ->> something2: data is transliterated Hi Adriano, While on this sort of subject are you able to offer any information about what happens to API text such as SQL statements and the like) sent to the server? (And details like relation names etc returned to the client.) There would appear to be potential complications with literal cast requests (eg: _ISO8859_1'abc') in connections using other UTF8 or other character sets etc. (Wondering if the client interface is expected to deal with such things - when asking for user input - or whether the server handles them in some vaguely sensible way (I suspect there is not always a good solution).) -- Geoff Worboys Telesis Computing |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-04-28 11:28:10
|
On 28/04/2011 08:20, Geoff Worboys wrote: > Adriano dos Santos Fernandes wrote: > ... >> Data is transliterated from its charset to client charset and >> vice-versa. > NONE/OCTETS ->> something: data is validated accordingly to something > something ->> NONE/OCTETS: nothing is done > something1 ->> something2: data is transliterated > > > Hi Adriano, > > While on this sort of subject are you able to offer any > information about what happens to API text such as SQL > statements and the like) sent to the server? (And details > like relation names etc returned to the client.) > They're interpreted in the client charset and converted (by rules above) to unicode_fss for storage. > There would appear to be potential complications with literal > cast requests (eg: _ISO8859_1'abc') in connections using other > UTF8 or other character sets etc. (Wondering if the client > interface is expected to deal with such things - when asking > for user input - or whether the server handles them in some > vaguely sensible way (I suspect there is not always a good > solution).) > In 2.5 the problems with introducer is fixed transforming the string (in memory for monitoring and in metadata) to x'HEXSTRING', so it's always ASCII-compatible. Adriano |
|
From: Geoff W. <ge...@te...> - 2011-04-28 11:57:50
|
Adriano dos Santos Fernandes wrote: > On 28/04/2011 08:20, Geoff Worboys wrote: >> ... >> While on this sort of subject are you able to offer any >> information about what happens to API text such as SQL >> statements and the like) sent to the server? (And details >> like relation names etc returned to the client.) >> > They're interpreted in the client charset and converted (by > rules above) to unicode_fss for storage. I see the FB v2.5 release notes mention: "Malformed characters are no longer allowed in data for UNICODE_FSS columns." which answers my first followup question. So according to the rules a client connection of NONE should be sending SQL statements compatible-with/able-to-be-validated-as UNICODE_FSS. For most purposes we can, at the client, assume UNICODE_FSS is the equivalent of UTF8, yes? Are there any client side distinctions we should be aware of? Thanks for your help, Adriano. -- Geoff Worboys Telesis Computing |
|
From: Geoff W. <ge...@te...> - 2011-04-29 07:11:54
|
Adriano dos Santos Fernandes wrote: > On 28/04/2011 08:20, Geoff Worboys wrote: >>... >> While on this sort of subject are you able to offer any >> information about what happens to API text such as SQL >> statements and the like) sent to the server? (And details >> like relation names etc returned to the client.) >> > They're interpreted in the client charset and converted (by > rules above) to unicode_fss for storage. Sorry to be a nuisance Adriano, but reviewing some code as a result of these discussions and have yet another question. As far as I can tell it is still required to use isc_dsql_execute_immediate to perform a CREATE DATABASE (if I've missed any relevant API change in the release notes please forgive me, I did look). So when isc_dsql_execute_immediate is called with CREATE DATABASE the database handle is null and there is no current connection character set. How is the statement string interpreted? -- Geoff Worboys Telesis Computing |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-04-29 11:33:52
|
On 29/04/2011 04:11, Geoff Worboys wrote: > > As far as I can tell it is still required to use > isc_dsql_execute_immediate to perform a CREATE DATABASE (if > I've missed any relevant API change in the release notes please > forgive me, I did look). > Could also be done with isc_create_database. > So when isc_dsql_execute_immediate is called with CREATE DATABASE > the database handle is null and there is no current connection > character set. How is the statement string interpreted? > CREATE DATABASE is preparsed in the client. It has SET NAMES <charset> clause. Client don't send it to server. It calls isc_create_database passing isc_dpb_lc_ctype. There is no SQL text command involved. Adriano |
|
From: Geoff W. <ge...@te...> - 2011-04-29 12:01:04
|
Adriano dos Santos Fernandes wrote: > Could also be done with isc_create_database. The IB6 API documentation notes this as: "The isc_create_database( ) method is not currently supported from user applications. It is for internal use only. Use isc_dsql_execute_immediate( ) to create a database with a valid database handle." Which I always took to mean that it was not to be used and I could not find any release notes changing that status. If this is now considered a public API then I think I will change my code to use that instead. >> So when isc_dsql_execute_immediate is called with CREATE DATABASE >> the database handle is null and there is no current connection >> character set. How is the statement string interpreted? >> > CREATE DATABASE is preparsed in the client. It has SET NAMES > <charset> clause. > Client don't send it to server. It calls isc_create_database > passing isc_dpb_lc_ctype. > There is no SQL text command involved. That will be why I had so much trouble finding how it was processed in the server source code ;-) Hmmm... SET NAMES I thought an ISQL only command. Can I send that via isc_dsql_execute_immediate or something to change some internal state in the client DLL? -- Geoff Worboys Telesis Computing |
|
From: Jason W. <ja...@jw...> - 2011-04-28 14:37:20
|
Adriano, PS. Good questions Geoff! > > While on this sort of subject are you able to offer any > > information about what happens to API text such as SQL > > statements and the like) sent to the server? (And details > > like relation names etc returned to the client.) > > > They're interpreted in the client charset and converted (by rules above) > to unicode_fss for storage. Where does the interpretation into the client charset take place? I've noticed the length returned when querying metadata names is 93 bytes. I presume this is actually intended to store 31 characters of Unicode_fss. So, when querying metadata directly, it should be decoded as Unicode_fss? > > There would appear to be potential complications with literal > > cast requests (eg: _ISO8859_1'abc') in connections using other > > UTF8 or other character sets etc. (Wondering if the client > > interface is expected to deal with such things - when asking > > for user input - or whether the server handles them in some > > vaguely sensible way (I suspect there is not always a good > > solution).) > > In 2.5 the problems with introducer is fixed transforming the string (in > memory for monitoring and in metadata) to x'HEXSTRING', so it's always > ASCII-compatible. How could this affect my layer of code that wraps the API? Do I need to be looking for a certain format in anything and doing more interpretation of results? Thanks, Jason LeRoy Wharton www.ibobjects.com |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-04-28 12:48:07
|
On 28/04/2011 08:57, Geoff Worboys wrote: > Adriano dos Santos Fernandes wrote: >> On 28/04/2011 08:20, Geoff Worboys wrote: >>> ... >>> While on this sort of subject are you able to offer any >>> information about what happens to API text such as SQL >>> statements and the like) sent to the server? (And details >>> like relation names etc returned to the client.) >>> >> They're interpreted in the client charset and converted (by >> rules above) to unicode_fss for storage. > I see the FB v2.5 release notes mention: "Malformed characters > are no longer allowed in data for UNICODE_FSS columns." which > answers my first followup question. So according to the rules > a client connection of NONE should be sending SQL statements > compatible-with/able-to-be-validated-as UNICODE_FSS. > > For most purposes we can, at the client, assume UNICODE_FSS > is the equivalent of UTF8, yes? Are there any client side > distinctions we should be aware of? > Yes. But UNICODE_FSS is currently validated as UTF-8 but in fact it should not allow 4-bytes characters. So doing it may result in problems when converting from UNICODE_FSS to UTF-8 or other character set. It's better to never use NONE charset, specially for the connection charset. Adriano |
|
From: Geoff W. <ge...@te...> - 2011-04-28 12:57:37
|
> Yes. But UNICODE_FSS is currently validated as UTF-8 but in > fact it should not allow 4-bytes characters. So doing it may > result in problems when converting from UNICODE_FSS to UTF-8 > or other character set. > It's better to never use NONE charset, specially for the > connection charset. Agreed, especially now that UTF8 is available well supported on Firebird. Mainly I wanted to be clear on this sort of thing with regard to IBObjects (and also some C++ work that I do). An interface library like this needs to do approximately the right thing even when the user chooses a character set of NONE. Thanks again. -- Geoff Worboys Telesis Computing |
|
From: Adriano d. S. F. <adr...@gm...> - 2011-04-29 12:12:32
|
On 29/04/2011 09:00, Geoff Worboys wrote: > Adriano dos Santos Fernandes wrote: >> Could also be done with isc_create_database. > The IB6 API documentation notes this as: > "The isc_create_database( ) method is not currently supported > from user applications. It is for internal use only. Use > isc_dsql_execute_immediate( ) to create a database with a > valid database handle." > > Which I always took to mean that it was not to be used and I > could not find any release notes changing that status. If > this is now considered a public API then I think I will change > my code to use that instead. > > There is nothing wrong with it, except a dumb last parameter. It's de facto public. >>> So when isc_dsql_execute_immediate is called with CREATE DATABASE >>> the database handle is null and there is no current connection >>> character set. How is the statement string interpreted? >>> >> CREATE DATABASE is preparsed in the client. It has SET NAMES >> <charset> clause. >> Client don't send it to server. It calls isc_create_database >> passing isc_dpb_lc_ctype. >> There is no SQL text command involved. > That will be why I had so much trouble finding how it was processed > in the server source code ;-) > > Hmmm... SET NAMES I thought an ISQL only command. Can I send that > via isc_dsql_execute_immediate or something to change some internal > state in the client DLL? > You confused things. ISQL own command is "SET NAMES ...". The client library understand "CREATE DATABASE ... SET NAMES ...". ISQL appends it own SET NAMES configured value to user issued CREATE DATABASE commands. Adriano |
|
From: Geoff W. <ge...@te...> - 2011-04-29 12:49:37
|
re: >> "The isc_create_database( ) ... > There is nothing wrong with it, except a dumb last parameter. > It's de facto public. Okay. That last parameter, I was just searching the code now for hints as to what it was. I just send a 0? > You confused things. ISQL own command is "SET NAMES ...". > The client library understand "CREATE DATABASE ... SET > NAMES ...". ISQL appends it own SET NAMES configured value > to user issued CREATE DATABASE commands. Yes, very confused. Now you mention it, I seem to remember reading about it before but can't find it in the release notes. It is noted in the v2.5.0 release notes, but without any explanation of its purpose. Is that because it's always been there and just never documented? (Else, do you know when it arrived - which version of FB?) Thanks for your help. -- Geoff Worboys Telesis Computing |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X