On 30-8-2012 10:11, Alex Peshkoff wrote:
> On 08/29/12 23:53, Mark Rotteveel wrote:
>> BTW: Out of curiosity: why is sqlind a pointer? Are there any other use
>> cases for it being a pointer, because honestly I don't really see the
>> point of having a pointer to a short in a structure like xsqlv
On 08/29/12 23:53, Mark Rotteveel wrote:
> BTW: Out of curiosity: why is sqlind a pointer? Are there any other use
> cases for it being a pointer, because honestly I don't really see the
> point of having a pointer to a short in a structure like xsqlvar.
IMHO people who designed SQLDA were much
On 29-8-2012 21:44, Dimitry Sibiryakov wrote:
> 29.08.2012 21:41, Mark Rotteveel wrote:
>> Why would that break existing applications and lead to Access
>> Violations?
>
> Read my comment in ticket. sqlind may be not initialized for non-nullable
> parameters.
Yes, this is what you get from wo
29.08.2012 21:41, Mark Rotteveel wrote:
> Why would that break existing applications and lead to Access
> Violations?
Read my comment in ticket. sqlind may be not initialized for non-nullable
parameters.
--
WBR, SD.
On 29-8-2012 21:41, Mark Rotteveel wrote:
> On 29-8-2012 21:31, Dimitry Sibiryakov wrote:
>> 29.08.2012 21:01, Mark Rotteveel wrote:
>>> I have created CORE-3913 as I think it would be a good idea to have the
>>> value of sqlind be leading instead of the nullable bit when sending
>>> parameters fro
On 29-8-2012 21:31, Dimitry Sibiryakov wrote:
> 29.08.2012 21:01, Mark Rotteveel wrote:
>> I have created CORE-3913 as I think it would be a good idea to have the
>> value of sqlind be leading instead of the nullable bit when sending
>> parameters from client to server.
>
> This change will bre
29.08.2012 21:01, Mark Rotteveel wrote:
> I have created CORE-3913 as I think it would be a good idea to have the
> value of sqlind be leading instead of the nullable bit when sending
> parameters from client to server.
This change will break existing applications leading to Access Violations i
On 29-8-2012 19:45, Mark Rotteveel wrote:
> On 25-8-2012 11:49, Mark Rotteveel wrote:
>> I have a question about handling NULL in XSQLVAR:
>>
>> Is it required to have sqldata set to null, or is setting sqlind to -1
>> sufficient? The reason I am asking is
>> http://tracker.firebirdsql.org/browse/J
On 25-8-2012 11:49, Mark Rotteveel wrote:
> I have a question about handling NULL in XSQLVAR:
>
> Is it required to have sqldata set to null, or is setting sqlind to -1
> sufficient? The reason I am asking is
> http://tracker.firebirdsql.org/browse/JDBC-271.
>
> When doing "SELECT cast(? as varchar
On 25-8-2012 12:25, Dimitry Sibiryakov wrote:
> 25.08.2012 12:20, Mark Rotteveel wrote:
>> I don't think that is entirely true
>
> Thinking is unreliable. Read this:
>
> // Make sure user has specified a data location (unless NULL)
> if (!xvar->sqldata && !*null_ind && (xvar->sqltype & ~1) != S
25.08.2012 12:20, Mark Rotteveel wrote:
> I don't think that is entirely true
Thinking is unreliable. Read this:
// Make sure user has specified a data location (unless NULL)
if (!xvar->sqldata && !*null_ind && (xvar->sqltype & ~1) != SQL_NULL)
return error_dsql_804(status, isc_dsql_sq
On 25-8-2012 11:52, Dimitry Sibiryakov wrote:
> 25.08.2012 11:49, Mark Rotteveel wrote:
>> Is it required to have sqldata set to null, or is setting sqlind to -1
>> sufficient?
>
> If parameter is nullable and sqlind == -1, sqldata is ignored by client
> library.
>
I don't think that is entir
25.08.2012 11:49, Mark Rotteveel wrote:
> Is it required to have sqldata set to null, or is setting sqlind to -1
> sufficient?
If parameter is nullable and sqlind == -1, sqldata is ignored by client
library.
--
WBR, SD.
13 matches
Mail list logo
