Skip to content
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

Array: Wrong work with VARCHAR elements [CORE1588] #2008

Open
firebird-automations opened this issue Nov 12, 2007 · 5 comments
Open

Array: Wrong work with VARCHAR elements [CORE1588] #2008

firebird-automations opened this issue Nov 12, 2007 · 5 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @ibprovider

Votes: 1

All know servers (FB / IB) incorrect work with VARCHAR arrays - they always do not use first two bytes with length of string.

The problem exists in sdl.cpp - static const UCHAR* sdl_desc(const UCHAR* ptr, DSC* desc):
blr_varying and blr_varying2 convert to incorrect dtype_cstring

-------- [code from FB2.1 sources]
case blr_varying2:
desc->dsc_dtype = dtype_cstring;
INTL_ASSIGN_TTYPE(desc, get_word(sdl));
desc->dsc_length = sizeof(USHORT);
break;

case blr\_varying:
	desc\-\>dsc\_dtype = dtype\_cstring;
	INTL\_ASSIGN\_TTYPE\(desc, ttype\_dynamic\);
	desc\-\>dsc\_length = sizeof\(USHORT\);
	desc\-\>dsc\_flags \|= DSC\_no\_subtype;
	break;

--------

I think, correction of this bug will be include
- new ODS
- some changes in gbak

Connection component can detect the new ODS and use true algorithms for VARCHAR arrays.

For old ODS - current cstring-algorithm

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 13403 ] => Firebird [ 14035 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @ibprovider

Version: 2.5 RC2 [ 10372 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Hmm, I do not see how is it related with ODS. On disk varchars are stored in vary format: 2 bytes length, after it string itself. It's sdl descriptor (tmp object) which contains dtype_cstring instead dtype_varying. Before touching this legacy code I wonder - what real problem does it cause to you, and certainly a kind of test to reproduce is highly desired.

@firebird-automations
Copy link
Collaborator Author

Commented by: @ibprovider

I offer append to new version of protocol (FB4?) the two new API functions - xxxx_put_slice2 and xxxx_get_slice2 with correct processing of VARYING arrays.

@firebird-automations
Copy link
Collaborator Author

Commented by: @ibprovider

I offer the fix this mistake in FB4 without any look to backward compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment