I have a simple select that do grouping where X is varchar (string) field:

select x, count(*) from table group by x;

When I do QBE on the field X, it generates having clause without quotas and select crash!!!

select x, count(*) from table group by x;
having (x = 01002)
/* Modified for QBE */

This works correctly at version 4.1.1.0 where is generated:
having (x = '01002')

How can I fix this behaviour?

Reagrds Vlada

Can you check the field type of the X field?

Hi Marco, thank you.

As I told before - varchar2(10), defined as TStringField at TOracleDataSet.

To reproduce:
create table test (x varchar2(10))
sql.text := 'select x, count(*) from test group by x';
qbemode := True;
qbedefinitions.field[0].Value := '01234'
ExecuteQBE

I did some research and there is result:

- when the field is created it has DataType ftString
- when the QBEMode is set to true, DataType change to 231

That's why the SQL is not correctly generated because you do not count on DataType 231.

For the users with the sources, the problem is in procedure OracleData.SetFieldSize. I guess it uses wrong offset somehow, so TField's FDataType is overwritten instead of FSize.

For ones without the source code access, you can patch the OracleData.dcu manually:
32bit - address on 2E0708 needs to be 58 instead of 50
64bit - unfortunatelly offset is too large for this instruction to be fixed, it needs to be replaced which breaks the dcu and I have no idea about dcu format. Thankfully it is working fine without fixing anyway. However I was not feeling comfortable knowing that some fields are just ramdomly set, so I have changed the three-byte instruction to three one-byte returns (addresses 4A2703, 4A2704, 4A2705 to C3)

Hopefully we get the official fix soon.

[quote=PreXident]
32bit - address on 2E0708 needs to be 58 instead of 50
64bit - unfortunatelly offset is too large for this instruction to be fixed, it needs to be replaced which breaks the dcu and I have no idea about dcu format. Thankfully it is working fine without fixing anyway. However I was not feeling comfortable knowing that some fields are just ramdomly set, so I have changed the three-byte instruction to three one-byte returns (addresses 4A2703, 4A2704, 4A2705 to C3)
[/quote]
Addresses are actually wrong, there are excess zeros. Use 2E078, 4A273, 4A274, 4A275 instead. Sorry for confusion.

Dear Marco, it is really so hard to implement this bugfix?

Dear Marco, is there a chance that this bug will be fixed soon?

Thanks and kind regards