We have a char* pointing to arbitrary data hence we need to cast
to the right type, othwerwise we retrieve the first byte only.
Change-Id: I6d3d08d15105a506c140044008c5255a8a8e4c39
Currently firebird uses /tmp and C://temp/ as default temporary directories,
both of which can be incorrect. Instead we now pass the correct temp
directories to firebird.
Change-Id: I807a47475e76600365e7a2ccfa78d755621dedb7
Reviewed-on: https://gerrit.libreoffice.org/5678
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
e.g. when growing m_aRow from size 3 to size 10
(that is, columnIndex==9),
the old code was initialising only position 9
while it we need to initialise all new positions,
that is positions 3 to 9.
Change-Id: I6a51b816104e33fdd7773b68e254e9bea50110ef
fillColumn is the only caller of impl_getBookmark, so all necessary
setup (in particular ensureCacheForColumn) is already done, and
does not need to be done in impl_getBookmark again.
Change-Id: Ic78b7dabd7c536abd9ed956baa178d685a63f713
SQLFetchScroll uses the bound columns, and writes to them.
This has two problems:
1) For non-bookmark columns, this happens in our buffers,
and at first sight could be innocuous.
However, it allows the driver to disallow us to use
SQLGetData on the same columns, which we intend to do...
2) For bookmark column, the "read bookmark from" and
"write bookmark to" buffers end up being the same.
This unnecessarily exposes us to driver bugs in this corner case.
Change-Id: I594d34cf5a64564766f06b49c86f8737961573c0
the buffer (aBookmark) is written to by SQLBulkOperations or
SQLSetPos, not by SQLBindCol, which merely sets up the instruction
that the next call should write there. So its finak size is known
only *after* the call that makes the write, obviously.
Change-Id: I4faaaeffc060433645188f0eda3d9958b087cf6c
This code was completely inverted. The row update operation
*reads* a bookmark (that is, what row to update), not *writes*
a bookmark.
So we were passing an empty bookmark, and thus the update was failing
because we were refering to a non-existent row.
Change-Id: I676b1a7727a88e13a3e465bd96cbbaf18dad2fa6
If this is incorrectly (or randomly set) then firebird will end up just
ignoring any input parameters (previously the case). The documentation
claims that -1 is the null indicator, however the inevitably-random
values previously provided (from malloc) also caused firebird to treat
all input data as null.
Change-Id: I79b9704df0a307ec493e74e782551b9b0ff109a2
Trying to reuse a statement that still has an open cursor leads to
errors -- in this usage isc_free_statement doesn't actually free
the statement but simply closes the db-internal cursor used by
that statement previously.
Change-Id: Iedbe42bc46e6b6f972b7b19f17a60d5f59bae28c
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
