Re: [sqlite] Is it a bug or "as designed"?

[Simon Slavin]

On 10 Mar 2018, at 7:15am, John Found  wrote:

> Simon Slavin  wrote:
> 
>> On 9 Mar 2018, at 7:49pm, John Found  wrote:
>> 
>>> In the current implementation "insert or replace" behave as the foreign 
>>> constraint is deferred.
>>> But according to documentation, all foreign constraints in SQLite are 
>>> immediate by default.
>> 
>>create table B (
>>aid references A(id) on delete cascade DEFERRABLE INITIALLY DEFERRED, 
>>ulti_data)
> 
> No difference at all. Because "insert or replace" always works as if the 
> constraint is deferred. 
> "insert or replace" always succeed to delete rows that are referenced by B 
> and defers the constraint enforcement until
> the end of the internal transaction. But at the end, a new row with the same 
> ID is inserted, so there is no 
> constraint violation anymore. 

John, I apologise.  I missed a paragraph in the documentation:

"If the current statement is not inside an explicit transaction (a 
BEGIN/COMMIT/ROLLBACK block), then an implicit transaction is committed as soon 
as the statement has finished executing. In this case deferred constraints 
behave the same as immediate constraints."

So please keep the CREATE TABLE statement the same as quoted above, but change 
your data commands to

BEGIN;
   insert or replace into A values (?1, ?2);
   insert into B values (?1, ?2);
COMMIT;

or even

BEGIN;
   insert or replace into A values (?1, ?2);
COMMIT;
insert into B values (?1, ?2);

Do these make things work the way you expect ?

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug or "as designed"?

[John Found]

On Sat, 10 Mar 2018 01:17:38 +
Simon Slavin  wrote:

> On 9 Mar 2018, at 7:49pm, John Found  wrote:
> 
> > In the current implementation "insert or replace" behave as the foreign 
> > constraint is deferred.
> > But according to documentation, all foreign constraints in SQLite are 
> > immediate by default.
> 
> John,
> 
> The documentation suggests that in SQLite foreign keys are not deferred by 
> default.  Section 4.2 of
> 
> 
> 
> talks about this and shows how to set up a foreign key to be deferred:
> 
> create table B (
> aid references A(id) on delete cascade DEFERRABLE INITIALLY DEFERRED, 
> ulti_data)
> 

No difference at all. Because "insert or replace" always works as if the 
constraint is deferred. 
"insert or replace" always succeed to delete rows that are referenced by B and 
defers the constraint enforcement until
the end of the internal transaction. But at the end, a new row with the same ID 
is inserted, so there is no 
constraint violation anymore. 


> Assuming you are using atomic commit (not using BEGIN/COMMIT, so SQLite 
> "inserts" them around that single statement) I /think/ this should allow your 
> code to work the way you intended.
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug or "as designed"?

[Simon Slavin]

On 9 Mar 2018, at 7:49pm, John Found  wrote:

> In the current implementation "insert or replace" behave as the foreign 
> constraint is deferred.
> But according to documentation, all foreign constraints in SQLite are 
> immediate by default.

John,

The documentation suggests that in SQLite foreign keys are not deferred by 
default.  Section 4.2 of



talks about this and shows how to set up a foreign key to be deferred:

create table B (
aid references A(id) on delete cascade DEFERRABLE INITIALLY DEFERRED, 
ulti_data)

Assuming you are using atomic commit (not using BEGIN/COMMIT, so SQLite 
"inserts" them around that single statement) I /think/ this should allow your 
code to work the way you intended.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug or "as designed"?

[R Smith]

On 2018/03/09 9:49 PM, John Found wrote:

On Fri, 9 Mar 2018 19:42:19 +
Simon Slavin  wrote:

You are right. And Jay Kreibich in his post above. But then the second 
solution from my post should be the correct behavior.

In the current implementation "insert or replace" behave as the foreign 
constraint is deferred.
But according to documentation, all foreign constraints in SQLite are immediate 
by default.



If an FK is created as immediate, it will fail at the conclusion (read: 
END OF) the statement that hits the FK check. If it is declared as 
DEFERRED it will wait all the way until the end of the Transaction when 
you try to commit.


Either way, many people get confused with REPLACE because it feels like 
UPDATE, it is not, REPLACE means (as have been pointed out) "REMOVE 
constraint-violating rows, THEN, ADD the given new row" - and more 
importantly - all of this happens INSIDE one single statement so that 
any FK checks will happen at the end of said statement AFTER the new row 
is added back, and so no constraint violation exists come checking time.


Triggers are a whole different matter, they are like EVENT handlers, and 
have to fire by binding contract the very moment the triggerable offense 
happens, which in the case of REPLACE is right in the middle of the 
statement, if (and only if) there was one or more rows in there that 
needed ousting.


What you probably wanted is an "UPSERT", which in theory is more an 
UPDATE OR INSERT than a REPLACE, and will cause at best an UPDATE 
Trigger to fire and no deletions will happen.  SQLite doesn't have a 
command like that, but you can easily simulate it by just issuing two 
commands:
First do the UPDATE... WHERE Key = X - which, if the record doesn't 
exist yet, will fail quietly because of the WHERE clause,
then do the INSERT OR IGNORE(...) - which will again fail quietly if it 
did already exist,
both of which won't break a Transaction, mess with the wrong triggers or 
constraint checks, will be very fast (considering the PK is used and 
only one of the two statements gets to do any work in IO terms)... and 
will always work perfectly and reliably fire only ON INSERT, ON UPDATE 
and ON DELETE triggers when those really happen.


The obvious downside to it being you having to formulate both an UPDATE 
and an INSERT statement in your code, which can be irritating, but then, 
if it's the best tool for the job...



I hope this shed some light on how it works and why the triggers and FKs 
fire differently (by design) and how to get the results you want.


Cheers,
Ryan


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug or "as designed"?

[Jay Kreibich]

> On Mar 9, 2018, at 1:42 PM, Simon Slavin  wrote:
> 

> "replace" means "delete the original row, then insert a new one”.

More properly, it means “delete any and all rows that might cause any conflict 
with inserting the new row.”  There really isn’t a concept of an “original” 
row, it just happens that the most common conflict is primary key.  It’s also 
true that inserting a single row with “insert or replace” can cause multiple 
rows to be deleted (if there are multiple constraints across multiple columns, 
for example).

 -j

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug or "as designed"?

[John Found]

On Fri, 9 Mar 2018 19:42:19 +
Simon Slavin  wrote:

> On 9 Mar 2018, at 7:11pm, John Found  wrote:
> 
> > "insert or replace" succeed without deleting the old rows from B.
> 
> "replace" means "delete the original row, then insert a new one".
> 
> In your code, figure out whether you need INSERT or UPDATE, and do the 
> appropriate one.
> 

You are right. And Jay Kreibich in his post above. But then the second solution 
from my post should be the correct behavior. 

In the current implementation "insert or replace" behave as the foreign 
constraint is deferred.
But according to documentation, all foreign constraints in SQLite are immediate 
by default.


> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug or "as designed"?

[Simon Slavin]

On 9 Mar 2018, at 7:11pm, John Found  wrote:

> "insert or replace" succeed without deleting the old rows from B.

"replace" means "delete the original row, then insert a new one".

In your code, figure out whether you need INSERT or UPDATE, and do the 
appropriate one.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug or "as designed"?

[Jay Kreibich]

Foreign keys enforcement can get tricky depending on the enforcement policy, 
transactions, and a lot of things.  I don’t have enough experience to comment 
on that fully.


I will say this, however, because it is a common mistake with a lot of 
different aspects of database behavior:

“Insert or replace” is NOT “insert or update.”

Insert always inserts a new row.  The only question is if it deletes 
conflicting rows (yes, plural) first.



With that in mind, the FK concept gets a little fuzzy.  It is a new row that 
just happens to have the same ID as an old row.  Does that mean the FK in B 
should still reference it?  I’d say no, because it is a brand new row… a 
different entity. If you want B to keep referencing the existing row, then 
update the row that is already there, don’t delete it and insert a new row on 
top of it.  I’d look into deferrable constraints to see if the behavior you’re 
looking for is supported.  Hopefully others can comment more on that.

 -j





> On Mar 9, 2018, at 1:11 PM, John Found  wrote:
> 
> 
> I have two tables with foreign constraint:
> 
>create table A ( id primary key not null, single_data );
>create table B ( aid references A(id) on delete cascade, multi_data);
> 
> Now I am periodically inserting data in A and B with the following queries:
> 
>insert or replace into A values (?1, ?2);
>insert into B values (?1, ?2); 
> 
> Unfortunately, after replacing some row in A, all previously inserted rows in 
> B got deleted, even if the value of ID does not changes. Here SQLite works 
> exactly as it first deletes the conflicting row from A and then inserting new.
> 
> Now, if I define the table B without "on delete":
> 
>create table B ( aid references A(id), multi_data);
> 
> "insert or replace" succeed without deleting the old rows from B.
> 
> In my opinion this behaviour is not consistent. The consistent solutions IMHO 
> are two:
> 
> 1. "insert or replace" succeed both in the first and in the second case 
> without deleting rows from B,
> 
> 2. "insert or delete" succeed in the first case, deleting all constrained 
> rows from B and fails in the second case with "FOREIGN KEY constraint failed".
> 
> The first case IMHO is more intuitive and natural. At least this was my 
> expectation when writing the code.
> 
> 
> -- 
> http://fresh.flatassembler.net
> http://asm32.info
> John Found 
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Is it a bug or "as designed"?

[John Found]

I have two tables with foreign constraint:

create table A ( id primary key not null, single_data );
create table B ( aid references A(id) on delete cascade, multi_data);

Now I am periodically inserting data in A and B with the following queries:

insert or replace into A values (?1, ?2);
insert into B values (?1, ?2); 

Unfortunately, after replacing some row in A, all previously inserted rows in B 
got deleted, even if the value of ID does not changes. Here SQLite works 
exactly as it first deletes the conflicting row from A and then inserting new.

Now, if I define the table B without "on delete":

create table B ( aid references A(id), multi_data);

"insert or replace" succeed without deleting the old rows from B.

In my opinion this behaviour is not consistent. The consistent solutions IMHO 
are two:

1. "insert or replace" succeed both in the first and in the second case without 
deleting rows from B,

2. "insert or delete" succeed in the first case, deleting all constrained rows 
from B and fails in the second case with "FOREIGN KEY constraint failed".

The first case IMHO is more intuitive and natural. At least this was my 
expectation when writing the code.


-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug ?

[Simon Slavin]

On 6 Nov 2014, at 3:13am, Andrei Yakimov  wrote:

> Problem is incorrect journal file, which is created on system reboot.
> Reproduce this condition relativity simple:
> 
> step 1:  we open db
> step 2:  write/update something to db.
> step 3:  switch journal to memory
> step 4:  write/update something to db.
> Do not close you SW keep it running and DB open
> step 5:  reboot your system or kill you SW not gracefully.

Please see



"The MEMORY journaling mode stores the rollback journal in volatile RAM. This 
saves disk I/O but at the expense of database safety and integrity. If the 
application using SQLite crashes in the middle of a transaction when the MEMORY 
journaling mode is set, then the database file will very likely go corrupt."

In other words, SQLite is operating as designed.  The ability to keep the 
journal in memory is supplied for databases where, if the system crashes, you 
would have to begin the task again anyway.  If you need your database to be 
recoverable after a crash, sorry, but you can't use that mode.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Is it a bug ?

[Andrei Yakimov]

Hi,
 I have using Sqlite for my small embedded projects for quite a while.
Recently we found a condition where is simple select all  does not operate
properly.
Problem is incorrect journal file, which is created on system reboot.
Reproduce this condition relativity simple:

step 1:  we open db
step 2:  write/update something to db.
step 3:  switch journal to memory
step 4:  write/update something to db.
Do not close you SW keep it running and DB open
step 5:  reboot your system or kill you SW not gracefully.

This reboot/kill will dump incorrect incorrect journal file to the file
system.
This will corrupt DB on next start.

I am using simple workaround:  switch journal to memory before any other db
access.
I will rebuild sqlite with journal to memory by default later.

This is reproduced very stable from 3.7.5  to latest release.
And I do not test  multiple  switching journal file/memory with update db
between switching.

I do not need fix for this. Just was thinking you would like to know about
this problem.

I appreciate what you are doing with this SW.

Andrei
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is it a bug?

[Joe Wilson]

--- Scott Hess <[EMAIL PROTECTED]> wrote:
> On 6/14/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
> > You can't infer a function's return type from its arguments.
> > Take the hypothetical function FOO(x). If I pass it a number, it will
> > return the number spelled out as TEXT, but if I pass it a BLOB it will
> > return its length*PI as a FLOAT.
> 
> Would it be reasonable to have:
> 
>   SELECT myfunc(x, y, z);
> 
> have an undefined return type, while:
> 
>   SELECT CAST(myfunc(x, y, z) AS INTEGER);
> 
> would return a well-defined return type?
> 
> After all, in SQLite you can't infer a column's type, either, you can
> only infer how the column is declared.  What it actually contains
> could be anything at all.

True enough, but in spite of my contrived FOO function, I'd think 
that 99% of functions would return one specific type or a NULL.
In the situations where this would not be the case, the CAST
operator, as you point out, would be a good way to override the
returned declared type.

I don't see this proposed type mechanism as being at odds with 
SQLite's typeless nature - it does not detract from it. It's not 
mandating policy - it's just suggesting a standard type reporting 
convention which you may elect to use or ignore.
It also would provide a facility to return column types for 
ad-hoc SELECT expressions that return no rows (i.e., you can't 
infer the column types from the first row because there are no
rows returned from the query).


   

Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Is it a bug?

[Scott Hess]

On 6/14/07, Joe Wilson <[EMAIL PROTECTED]> wrote:

You can't infer a function's return type from its arguments.
Take the hypothetical function FOO(x). If I pass it a number, it will
return the number spelled out as TEXT, but if I pass it a BLOB it will
return its length*PI as a FLOAT.


Would it be reasonable to have:

 SELECT myfunc(x, y, z);

have an undefined return type, while:

 SELECT CAST(myfunc(x, y, z) AS INTEGER);

would return a well-defined return type?

After all, in SQLite you can't infer a column's type, either, you can
only infer how the column is declared.  What it actually contains
could be anything at all.

-scott

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Is it a bug?

[BardzoTajneKonto]

> The code changes are not that complex.  The hard part is getting
> me to agree to such a change.  Surely by now you have come to
> better understand my views toward static typing

Isn't this decision already made? Strict affinity mode is mentioned on 
official SQLite site suggesting that it will happen.


--
Cywilizacje powstaja z gliny i zelaza. Travian 
>>> http://link.interia.pl/f1a7e


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Is it a bug?

[Joe Wilson]

--- [EMAIL PROTECTED] wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> > 
> > As a possible extension one could see sqlite3_create_function taking an 
> > optional argument with a hint as to its return type that sqlite may use 
> > for sqlite3_column_decltype. But SQLite does not currently return any 
> > column types for any ad-hoc expression. So this would not be a trivial
> > change.
> > 
> 
> The code changes are not that complex.  The hard part is getting
> me to agree to such a change.  Surely by now you have come to
> better understand my views toward static typing

No doubt.

This issue comes up frequently when making database drivers for 
JDBC, ODBC, R, (you name the language) as they often expect static 
column types in result sets.  Yes, I've hacked my way around it, 
as has every other driver writer, but it would be nice if everyone 
did not have to reinvent the wheel each time. 

In a hypothetical implementation, one could preserve backwards 
API compatiblity by overloading the zFunctionName argument by
tacking on a TYPE suffix (i.e., "myfunction:TYPE") to convey the 
type being returned by the function.

 int sqlite3_create_function(
   sqlite3 *,
   const char *zFunctionName,
   int nArg,
   int eTextRep,
   void *pUserData,
   void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
   void (*xStep)(sqlite3_context*,int,sqlite3_value**),
   void (*xFinal)(sqlite3_context*)
 );

But it would probably be easier to convince all the other popular 
relational databases that they should change to exclusively use 
dynamic typing.
;-)


   

Moody friends. Drama queens. Your life? Nope! - their life, your story. Play 
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Is it a bug?

[drh]

Joe Wilson <[EMAIL PROTECTED]> wrote:
> 
> As a possible extension one could see sqlite3_create_function taking an 
> optional argument with a hint as to its return type that sqlite may use 
> for sqlite3_column_decltype. But SQLite does not currently return any 
> column types for any ad-hoc expression. So this would not be a trivial
> change.
> 

The code changes are not that complex.  The hard part is getting
me to agree to such a change.  Surely by now you have come to
better understand my views toward static typing

--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Is it a bug?

[Joe Wilson]

--- [EMAIL PROTECTED] wrote:
> Thank you Joe.  At least sqlite3_column_type gives me a column type I 
> can use as
> a hint.
> 
> The issue is that I have a well-defined column type naming convention for my
> wrapper classes to look for (INT, TEXT, FLOAT, BLOB, etc.).  For binary data
> fields, its BLOB.  For other field types, when encrypted they should be
> prefixed with BLOB (eg. BLOB_INT, BLOB_TEXT, BLOB_FLOAT), so that my low-level
> execute function can provide hints to the downstream result-set parsing to use
> for converting types.
> 
> Wouldn't it be entirely possible to provide the column's type if the function
> used only a single column in its parameter list?  For example, consider the

You can't infer a function's return type from its arguments.
Take the hypothetical function FOO(x). If I pass it a number, it will
return the number spelled out as TEXT, but if I pass it a BLOB it will
return its length*PI as a FLOAT.

As a possible extension one could see sqlite3_create_function taking an 
optional argument with a hint as to its return type that sqlite may use 
for sqlite3_column_decltype. But SQLite does not currently return any 
column types for any ad-hoc expression. So this would not be a trivial
change.

> UPPER function.  In cases where its just used to convert a single column to
> upper-case, couldn't Sqlite just use that column's data type?  E.g.,
> 
>  UPPER(FirstName)
> 
> It should be an easy thing to provide this info.  Even if there were multiple
> fields involved, if they were all the same data type, Sqlite could know this
> and provide the common type.  E.g.,
> 
>  UPPER(FirstName + LastName)

Even a simple operator like '+' you cannot easily determine the return 
type of its expression without evaluating it - and even then it may 
return a FLOAT in one invocation and TEXT in a different invocation.
With some static expression analysis you could infer the return type
for a number of input combinations, but this would require a fair bit
of new code.

> If both field types were BLOB_TEXT, then that should be provided.  Only 
> in cases
> where there were multiple columns and the data types were different 
> would a NULL
> be returned.
> 
> This would certainly be an improvement for Sqlite, would it not?
> 
> cheers
> -brett
> 
> Quoting Joe Wilson <[EMAIL PROTECTED]>:
> 
> > --- [EMAIL PROTECTED] wrote:
> >> I have a user-defined function named DECRYPT, which decrypts column data
> >> encrypted by my other UDF named ENCRYPT.
> >>
> >> The UDF callback function (which does the decrypting) calls 
> >> sqlite3_result_blob
> >> after decrypting the data.  Sqlite does return the data OK...BUT!  
> >> It doesn't
> >> provide the data type for the column when I call sqlite3_column_decltype 
> >> for
> >> the column.  The return value is NULL.  I must have the column data 
> >> type, else
> >> my code can't properly interpret the value.   This must be a bug, right?
> >
> > As far as I know, SQLite has to way of knowing what the column type
> > is in the case of a function:
> >
> >   "If the Nth column of the result set is not a table column,
> >   then a NULL pointer is returned."
> >
> >   http://www.sqlite.org/capi3ref.html#sqlite3_column_decltype
> >
> > You can interrogate the first row's column values with
> > sqlite3_column_type as a workaround (assuming the column in subsequent
> > rows are of the same type):
> >
> >   http://www.sqlite.org/capi3ref.html#sqlite3_column_type



   

Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for 
today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Is it a bug?

[Joe Wilson]

--- [EMAIL PROTECTED] wrote:
> I have a user-defined function named DECRYPT, which decrypts column data
> encrypted by my other UDF named ENCRYPT.
> 
> The UDF callback function (which does the decrypting) calls 
> sqlite3_result_blob
> after decrypting the data.  Sqlite does return the data OK...BUT!  It doesn't
> provide the data type for the column when I call sqlite3_column_decltype for
> the column.  The return value is NULL.  I must have the column data type, else
> my code can't properly interpret the value.   This must be a bug, right?

As far as I know, SQLite has to way of knowing what the column type 
is in the case of a function:

  "If the Nth column of the result set is not a table column, 
  then a NULL pointer is returned."

  http://www.sqlite.org/capi3ref.html#sqlite3_column_decltype

You can interrogate the first row's column values with 
sqlite3_column_type as a workaround (assuming the column in subsequent
rows are of the same type):

  http://www.sqlite.org/capi3ref.html#sqlite3_column_type



 

Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

[sqlite] Is it a bug?

[brettg]

I have a user-defined function named DECRYPT, which decrypts column data
encrypted by my other UDF named ENCRYPT.

The UDF callback function (which does the decrypting) calls sqlite3_result_blob
after decrypting the data.  Sqlite does return the data OK...BUT!  It doesn't
provide the data type for the column when I call sqlite3_column_decltype for
the column.  The return value is NULL.  I must have the column data type, else
my code can't properly interpret the value.   This must be a bug, right?

-brettg


This message was sent using IMP, the Internet Messaging Program.



-
To unsubscribe, send email to [EMAIL PROTECTED]
-