Issue Details (XML | Word | Printable)

Key: CORE-6303
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Tony Whyman
Votes: 0
Watchers: 3

If you were logged in you would be able to see more operations.
Firebird Core

Error writing to TIMESTAMP/TIME WITH TIME ZONE array

Created: 14/May/20 01:37 PM   Updated: 21/Jul/20 11:16 PM
Component/s: Engine
Affects Version/s: 4.0 Beta 2
Fix Version/s: 4.0 RC 1

Environment: Linux Mint 19.3 amd64 with LI-T4.0.0.1960 Firebird 4.0 Beta 2

QA Status: Deferred
Test Details:
Deferred until FDB will support new TIME WITH TIMEZONE data type introduced in FB 4.x.
Letter from Alex 21.07.2020 23:43

 Description  « Hide
I have set up a test of TIME/TIMESTAMP WITH TIME ZONE arrays. The test is failing when putslice is called, with the error message reporting an error writing data to the connection (send_packet/send).

The test table is created using:

Create Table FB4TestData_ARTZ (
    RowID Integer not null,
    TimeCol TIME WITH TIME ZONE [0:16],
    TimestampCol TIMESTAMP WITH TIME ZONE [0:16],
    Primary Key(RowID)

The test is run by filling each array with 17 values and then writing the array buffer to the server using "putslice". The SDL is identical to a known good SDL block for an array of TIMESTAMP (WITHOUT TIME ZONE) except that the data type is blr_sql_time_tz or blr_timestamp_tz as appropriate. I have seen a connection drop previously when using putslice when the SDL is mis-formatted. However, I can see no problem in this case.

The one oddity I can see is that the element size being returned from the metadata is "8" for a TIME WITH TIME ZONE array and "12" for a "TIMESTAMP WITH TIME ZONE" array. Given the data structures, I would have expected "6" and "10". However, I have also checked the metadata for non-array TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE columns and these also return "8" and "12" respectively. If I execute a 'SET BIND OF TIME ZONE TO EXTENDED' statement, then the non-array column sizes remain as "8" and "12" even though the data types have changed to SQL_TIME_TZ_EX and SQL_TIMESTAMP_TZ_EX, respectively. I presume that field alignment is being forced to a four byte boundary.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 14/May/20 01:47 PM
Thats's almost for sure same bug