Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-26 Thread Michael Roth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D. Richard Hipp wrote:
| All core features have been thoroughly tested.  I'm looking for problems
| with the API.  Do we need new parameters on some functions?  Do we need
| to change the semantics of some functions?
Yes! I discoverd an issue with the error handling in sqlite3_column_name
and sqlite3_column_decltype (Version 3.0.3 I think):
They return a null pointer, if the index is out of range. They don't set
a error code in the sqlite3* data.
But, if sqlite3_column_blob/text/double/int are used with a wrong index
they behave as the requested column data was NULL and they set a
SQLITE_RANGE error.
In my opinion, sqlite3_column_name/decltype should it do the same way.
I.e. return an empty string ("") and set SQLITE_RANGE in the cases the
index was invalid.
Michael Roth

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBLbAdSIrOxc3jOmoRAlf/AKC1syGv0Wx0Jc0tWI0zQSuWC8vkDwCfZnRQ
a8Bf7mLfCGjLlyIHXsE/sQo=
=as6m
-END PGP SIGNATURE-


Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-25 Thread Ara.T.Howard
On Wed, 25 Aug 2004, D. Richard Hipp wrote:
Ara.T.Howard wrote:
On Tue, 24 Aug 2004, D. Richard Hipp wrote:
The more people use SQLite version 3, the faster it will leave beta
status

in particular, which features would you say need tested?  i have many uses
for sqlite, perhaps i may be able to start using 3 for some of my projects.
All core features have been thoroughly tested.  I'm looking for problems
with the API.  Do we need new parameters on some functions?  Do we need
to change the semantics of some functions?  Do we need to change the
semantics of some of the SQL.
Once the code comes out of beta, the API is frozen.  Any deficiencies
we'll just have to live with.  So if there is anything you think needs
to be added which cannot be added in a backwards compatible way, you
need to speak up now.
Typically these kinds of problems are only discovered after heavy use,
which is why I'm asking for more users before I move out of beta.
The question of Host Parameter Names and their format is the kind of
thing that needs to be resolved now, before leaving beta.  I just changed
the parsing of Host Parameter Names (a.k.a. bind parameters) from
":NNN:" where NNN is a number to ":AAA" where AAA is any alphanumeric
text.  Those kind of changes need to be identified soon before the
wrong implementation gets frozen into the design forever.
Thanks for your help.
i'll talk with jamis buck about this, he did the (most excellent) ruby binding
to sqlite and i am now planning on using it heavily in a production system.
however, the current binding is for 2.8 only.  i'll speak with him about 3 and
see if there is anything i can do to assist with that code (assuming he plans
to do a version 3 binding) - which obviously would stress the api - and
perhaps begin using it in some test clusters i am running via sqlite based
code.
i'm curious, have many changes been made to the locking strategy which might
affect concurent NFS usage?  i've read the new docs, but have not had time to
look at the source.  for my usage i actually use an additional lock file to
ensure that there can be exactly one writer to an sqlite database regardless
of any byte range write locks it may use internally.  my biggest issue to date
has been to detect broken locks and i've developed a userland algorithim to do
so and automatically clear them - useful for nfs work...  anyhow, any tidbits
regarding changes likely to affect nfs useage are appreciated...
also, in the docs you mention 'opening the directory and calling fysnc on it'.
you mean the directory is opened for writing?
cheers.
-a
--
===
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. 
|   --Dogen
===


Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-24 Thread Christian Werner
"D. Richard Hipp" wrote:
> ...
> All core features have been thoroughly tested.  I'm looking for problems
> with the API.  Do we need new parameters on some functions?  Do we need
> to change the semantics of some functions?  Do we need to change the
> semantics of some of the SQL.
> ...

Please re-introduce the SQLite API function sqlite_libversion() as
sqlite3_libversion() in SQLite3. It might be needed for Win32 DLLs.

Best regards,
Christian


Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-24 Thread D. Richard Hipp
Ara.T.Howard wrote:
> On Tue, 24 Aug 2004, D. Richard Hipp wrote:
>>
>> The more people use SQLite version 3, the faster it will leave beta
>> status
>
>
> in particular, which features would you say need tested?  i have many uses
> for sqlite, perhaps i may be able to start using 3 for some of my projects.
>
All core features have been thoroughly tested.  I'm looking for problems
with the API.  Do we need new parameters on some functions?  Do we need
to change the semantics of some functions?  Do we need to change the
semantics of some of the SQL.
Once the code comes out of beta, the API is frozen.  Any deficiencies
we'll just have to live with.  So if there is anything you think needs
to be added which cannot be added in a backwards compatible way, you
need to speak up now.
Typically these kinds of problems are only discovered after heavy use,
which is why I'm asking for more users before I move out of beta.
The question of Host Parameter Names and their format is the kind of
thing that needs to be resolved now, before leaving beta.  I just changed
the parsing of Host Parameter Names (a.k.a. bind parameters) from
":NNN:" where NNN is a number to ":AAA" where AAA is any alphanumeric
text.  Those kind of changes need to be identified soon before the
wrong implementation gets frozen into the design forever.
Thanks for your help.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-24 Thread Ara.T.Howard
On Tue, 24 Aug 2004, D. Richard Hipp wrote:
Mauricio Piacentini wrote:
I will update SQLiteBrowser to use version 3 when it leaves beta 
status

The more people use SQLite version 3, the faster it will leave
beta status
in particular, which features would you say need tested?  i have many uses for
sqlite, perhaps i may be able to start using 3 for some of my projects.
regards.
-a
--
===
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. 
|   --Dogen
===


Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-24 Thread Mauricio Piacentini
D. Richard Hipp wrote:
Mauricio Piacentini wrote:
I will update SQLiteBrowser to use version 3 when it leaves beta 
status

The more people use SQLite version 3, the faster it will leave
beta status
Oh, ok. Good to know. I will then try to release a beta version asap, to 
help testing.

Can you rig SQLiteBrowser so that it links against both 2.8 and 3.0
and uses whichever is appropriate for the database it is reading?
I already have a version linked to both versions of the library. I was 
planning to make it able to convert from 2 -> 3, but operate in 3.x 
format only from now on. I will investigate what it takes to make it 
able to operate with both formats, however.

Regards,
Mauricio


Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-24 Thread D. Richard Hipp
Mauricio Piacentini wrote:
I will update SQLiteBrowser to use version 3 when it leaves beta status
The more people use SQLite version 3, the faster it will leave
beta status
Can you rig SQLiteBrowser so that it links against both 2.8 and 3.0
and uses whichever is appropriate for the database it is reading?
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


Re: [sqlite] Script perl e python, I can't open database from sqlite

2004-08-24 Thread Mauricio Piacentini
SQLite version 3.0.4
Enter ".help" for instructions
qlite> .databases
Error: file is encrypted or is not a database
sqlite> .tables
Error: file is encrypted or is not a database
But if I open this database with sqlitebrowser I don't have errors. Why 
sqlite doesn't open it ??? This error is under linux and windows.
Your Perl module and SqliteBrowser are both still using SQLite version 
2.8.x, so they produce databases in the SQLite 2.1 format. You are 
trying to read these with SQLite version 3, that's the reason why it 
does not work.
I will update SQLiteBrowser to use version 3 when it leaves beta status, 
probably after the next release.

Regards,
Mauricio


[sqlite] Script perl e python, I can't open database from sqlite

2004-08-24 Thread Panther
If I create db with script perl and python after if I try to open db 
with sqlite I've this error:
Error: file is encrypted or is not a database

This is the script on windows, I use last perl's modules and last sqlite 
version :
#!c:\perl\bin\perl.exe
use DBI;
use strict;
my $dbh=DBI->connect ("dbi:SQLite:dbname=c:\\sqlite\\dizio.sql") or die 
"$!";
my $sth = $dbh->do("CREATE TABLE di (indice int, dato char(10))");
my $sth = $dbh->prepare("INSERT INTO di VALUES (?, ?)");
$sth->execute(1, 'ciao');
$sth = $dbh->prepare("select * from di;");
$sth->execute();
while ( my @row=$sth -> fetchrow_array() )
{
print "uno: $row[0], due: $row[1]\n";
}
$dbh -> disconnect();

If I try:
sqlite dizionario.sql
SQLite version 3.0.4
Enter ".help" for instructions
qlite> .databases
Error: file is encrypted or is not a database
sqlite> .tables
Error: file is encrypted or is not a database
But if I open this database with sqlitebrowser I don't have errors. Why 
sqlite doesn't open it ??? This error is under linux and windows.