[sqlite] MyJSQLView Version 3.30 Released

[danap]

The MyJSQLView project has released a preliminary production version to
address several reported problems with the application. Since this release
is to correct these bugs a more fully vetted release will be forth coming
by the end of the month or early next.

The release Version 3.30 corrects the running of the application
on specifically the Ubuntu Linux OS with the Gnome desktop. Because of
the type of bug that was discovered it is possible this may effect all
uses of the application on the Gnome desktop. The second issued addressed
by the release is the lack to properly export PDF Summary Table data. A
failure on the project to properly build the last release with an updated
iText library file inclusion was the cause.

Dana M. Proctor
MyJSQLView Project Manager
http://dandymadeproductions.com/projects/MyJSQLView/

MyJSQLView provides an easy to use open source Java based user interface
frontend for viewing, adding, editing, or deleting entries in the HSQL,
MySQL, Oracle, PostgreSQL, and SQLite databases. A query frame allows
the building of complex SELECT SQL statements. The application allows
easy sorting, searching, and import/export of table data.

The MyJSQLView application uses the Xerial SQLiteJDBC to communicate
with the SQLite database.
http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC#WhatisdifferentfromZentussSQLiteJDBC

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

Re: [sqlite] Read only scaling optimization

[Alexey Pechnikov]

2011/8/12 Pavel Ivanov :
> It's a little surprising to me that with all the same conditions 2
> files residing on the same drive have better performance than the same
> files residing on different drives. Theoretically that shouldn't
> happen.

Yes, it's not right behaviour. Is needed the sources of the test programm.

-- 
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Strange behaviour with fork/close.

[Kevin Martin]

On 14 Aug 2011, at 12:18, Kevin Martin wrote:

> I am however very confused If
> anyone has the time to read this and give a hint as to what might be
> going on, it would be greatly appreciated.

Why do you always figure things out after you have posted them to the  
mailing list?

The problem was I had closed stdin, so when I opened the database in  
the execed child it was being opened on file descriptor 0. Then, when  
I did close(STDIN_FILENO) I inadvertently closed the database. Hence  
why the query was failing, and why closing/opening it fixed the problem.

Kev

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

[sqlite] Strange behaviour with fork/close.

[Kevin Martin]

Hello,

I have read the FAQ, and know that you can't fork with an open  
database connection. I'm not doing that. I am however very confused If  
anyone has the time to read this and give a hint as to what might be  
going on, it would be greatly appreciated.

Thanks,
Kevin Martin

---

Firstly, this is running on mac os x 10.5.8 with sqlite 3.7.7.1  
compiled directly into all binaries.

Here is the situation:

parent process
   opens database
   does stuff
   closes database (sqlite3_close returns SQLITE_OK)
   creates pipe
   forks
   closes write end of pipe
   reopens database
   reads data from pipe until it closes
   continues on (all database queries issued here work)

child (relevant code)
 global_ios->notify_fork(boost::asio::io_service::fork_child);

 signal(SIGHUP, SIG_IGN);
 setsid();

 //close the socket, pipe, and stdin
 global_currentSocket.reset();
 close(pipefd[0]);
 close(STDIN_FILENO);

 //send stdout and stderr to the pipe
 dup2(pipefd[1], STDERR_FILENO);
 dup2(pipefd[1], STDOUT_FILENO);
 close(pipefd[1]);

 execl(arguments)

Now, in the execed child the database is opened and I can run queries  
and everything is fine until I do
 close(STDIN_FILENO);
 close(STDOUT_FILENO);
 close(STDERR_FILENO);
 open("/dev/null",O_RDONLY);
 open("/dev/null",O_WRONLY);
 open("/dev/null",O_WRONLY);

After this point, any sqlite3_step() calls return SQLITE_ERROR.  
Although I have forgotten the exact details, there was some very  
similar code that consistently produced SQLITE_IOERR instead.

If I close the database before I close stdout/stdin/stderr and reopen  
it afterwards there is no problem and everything works as expected.

The thing I find really confusing is if I run the execed child  
directly from the shell instead of from the parent, there is no  
problem and everything works fine. Which makes me think I am doing  
something hideously wrong whilst forking.

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

Re: [sqlite] null handling import

[Jean-Christophe Deschamps]

Mattew,

>   Obviously I am not as well versed in sqlite as you are. I hate to 
> hate myself, but am still continuing with reading somewhat ancient 
> files into a somewhat cohorrent database.
>
>Thanking you for your time and trouble,
>
> Matthew
>
>p.s. shame about the parsing of comma delimited files though. Goodnight.

FYI I routinely have to gather a number of data sources into SQLite 
DBs. I've found SQLite Expert very useful for that.

Here's a sample nonsensical input:

id,sequence,desc,supplier,reference,flavour,weight
132,0,"text",,"",,4
28,0,"more text, doesn't matter","Dell",87,111
5403,1,"","secondary text",,,

and here's the DDL that Expert made out of it:

CREATE TABLE [tst] (
   [id] INTEGER,
   [sequence] CHAR(1),
   [desc] CHAR(25),
   [supplier] CHAR(14),
   [reference] INTEGER,
   [flavour] INTEGER,
   [weight] INTEGER);

now the actual table data:

RecNo   id sequence desc  supplier   reference 
flavour weight
-   - -- - 
--- --
 1  132 
0text  (null) 0  (null)  4
 2   28 0more text, doesn't matter 
Dell  87 111  0
 3 5403 1  secondary 
text(null)  (null) (null)

Note how Expert handles successive commas as 'no value supplied', hence 
NULL in SQL parlance.

--
j...@antichoc.net  

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