Re: [sqlite] --prefix
[In the message "[sqlite] --prefix" on May 29, 13:11, "Smith1, Robert E" writes:] > Hi, > > I am trying to install sqlite3 on Sun Solaris 2.8. I am not root so I > cannot install to /usr/local. I start configure with > --prefix=/ptmp/usr/localto try to get it to install to a different > directory. This is the correct syntax for what you are trying to do. > But I get the same > > error: > > /ptmp/bld/> make install > > tclsh ../sqlite-3.3.17/tclinstaller.tcl 3.3 > > can't create directory "/usr/local/lib/tcl8.4/sqlite3": read-only file > system > > while executing > > "file mkdir $LIBDIR/sqlite3" > > (file "../sqlite-3.3.17/tclinstaller.tcl" line 15) > > *** Error code 1 > > make: Fatal error: Command failed for target `tcl_install' I have not done this myself but I think I know what the problem is. Your sqlite installation is correctly figuring out the prefix and is being installed in the right place. There is an additional piece of software that is being installed, though. It is tclsqlite extension to tcl. This is probably a shared library and a tcl loader, which reacts to the "package require tclsqlite" command in tcl. The question is, where are those being installed. Since they are being used by tcl and not by sqlite, they get installed where tcl can see them. Since you are probably using system wide tclsh and not the one (not) installed in /ptmp/usr/local, the system wide one is trying to install the extension where it will find it. That is most likely its own library area. The hint is: > can't create directory "/usr/local/lib/tcl8.4/sqlite3": read-only file Try running: which tclsh and you will probably find that it is /usr/local/bin/tclsh8.4 or something like that. > Is my syntax for --prefix correct and is that supposed to correct the > above error? So what is the solution here? You can run: make -k install and it will install everyting that it can, excluding tcl extension. If you want to run tclsqlite from tcl, you can by hand copy the shared library which would be placed in: $LIBDIR/sqlite3 somewhere you can write, /ptmp/usr/local/lib perhaps. Before you run "make -k install", run "make -n install" and save the output, since it will tell you what it was planning to do with tclsqlite files. When in the future you want to use tclsqlite from tclsh, instead of: package require tclsqlite you would have to try something like load /ptmp/usr/local/lib/libtclsqlite3.so I am sure there are other solutions, but this might get you moving. > Robert Nikola - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Capturing output from SQLlite with variables in a BASH script
[In the message "[sqlite] Capturing output from SQLlite with variables in a BASH script" on Jun 22, 13:02, litenoob writes:] > > Hi, I'm wondering how to write a BASH script that will capture my SQLite > output. > > I can do it for a single line with something like this: > > somevar=`sqlite3 dbfilename "SELECT name FROM tablename WHERE name='smith' > LIMIT 1;"` > > However, if I want to do anything with multiple lines, I haven't figured out > a good way. So far, I'm using a workaround by outputting to a file, then > reading it after I exit the SQLite commandline, but that slows down the > script significantly. > > e.g. > > sqlite3 dbfilename << EOF > > .output temp1 > select id from tablename where name = "bush"; > .output temp2 > select id from tablename where name = "osama"; > > .quit > EOF > > read id1 < temp1 > read id2 < temp2 > > What's the better way to do this without actually writing to a file? Well, you can combine the two: id=`sqlite3 dbfilename <
Re: [sqlite] What about with LAST_INSERT_ROWID() ?
[In the message "[sqlite] What about with LAST_INSERT_ROWID() ?" on Jun 22,
15:09, litenoob writes:]
>
> Hmm.. don't know sed or awk, but I suppose this weekend would be a good time
> to learn!
>
> Alright, going along with this, is there a better way to get the last row id
> inserted? This is my (completely inefficient) workaround:
>
> - - - - -
>
> sqlite3 $dbfilename << EOF
>
> INSERT INTO tablename (col1, col2) VALUES ("foovaluoo", 3.14159265);
>
> .output t_rowid.tmp
> SELECT LAST_INSERT_ROWID() FROM $db_table LIMIT 1;
>
> .quit
> EOF
>
> read tehrowish < t_rowid.tmp
> rm t_rowid.tmp
>
> - - - - -
>
> Basically, I want to insert something into the DB, then get the row id of
> that insertion. I know I have to do it in one session, otherwise
> LAST_INSERT_ROWID() returns 0.
Well cut, sed, awk would be usefull if you are to push this idea
further.
For your needs I just tested the following code:
--
#/bin/sh
ROW_ID=`sqlite3 test.db <
Re: [sqlite] Re: how do i declare and use variables in sqlite?
[In the message "[sqlite] Re: how do i declare and use variables in sqlite?" on Aug 2, 18:22, "Igor Tandetnik" writes:] > Chase <[EMAIL PROTECTED]> wrote: > > how do i declare and use variables in sqlite? > > You don't. You declare and use variables in whatever program you write > that runs SQLite statements. > > Igor Tandetnik This is certainly true, but there might be cases where one wants to keep certain results between sql statements and reuse them. While this conceptual solution is certainly not the Variable it sort of gets the job done. create temporary table vars (name text, value something); -- insert into vars set name="x", value=0; -- ... where something = (select value from vars where name="x")... I real life you might want to create better named temporary table directly with select and use its values without having to search through names. If this is slow you can attach in memory database which would then be used to store "variables". Nikola - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Re: Re: how do i declare and use variables in sqlite?
[In the message "Re: [sqlite] Re: Re: how do i declare and use variables in
sqlite?" on Aug 3, 11:47, "Paul Harris" writes:]
> > >> create temporary table vars (name text, value something);
> > >> --
> > >> insert into vars set name="x", value=0;
> > >> --
> > >> ... where something = (select value from vars where name="x")...
> > >>
> > >
> > > I tried doing this, but there doesn't seem to be a way to do the same
> > > thing with an UPDATE command ?
> >
> > No way to do what with UPDATE command? What exactly are you trying to
> > do, and failing?
> >
>
> i've just realised the last statement ("...where etc etc") is probably
> supposed to be part of a select statement.
Yeap, sorry for being "too conceptual", dislexic (insert/update, thanks Igor)
and obviously too confusing :-).
> anyway, this is what i'm trying to do:
>
> eg 1
> select @somevar := column1 from table1;
> update table2 set column2 = @somevar;
Try:
create temporary table var1 select column1 from table1;
update table2 set column2 = (select column1 from var1);
As written the second comand will likely not do what was intended
since var1 might have more than 1 row and there is no constraint
so every row in table2 will be affected. I assume that real
implementation will deal with this.
>
> eg2
> update table1,table2 set column2=column1;
I believe that SQLite only updates one table at the time, so
this will have to be rewriten, but where is the variable here?
Perhaps:
update table2 set column2=(select column1 from table1);
with some where clauses?
>
> eg3 (using temp table - how to do this?)
> create temporary table vars (name text, value something);
> insert into vars set name="x", value=0;
> update vars,table2 set column2=value where name = 'x';
Is the code above (eg1) what you are lookin after?
Nikola
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] 1-way replication best practices?
[In the message "Re: [sqlite] 1-way replication best practices?" on Sep 28, 11:29, Dan Kennedy writes:] > On Thu, 2007-09-27 at 14:26 -0700, Cyrus Durgin wrote: > > hi, > > > > i'm using sqlite3 in a small project that will run on multiple servers. > > only one of the instances will be read-write to the database, the others are > > all read-only. i understand that the recommended process for replication on > > the read-write instance looks something like: > > > > BEGIN EXCLUSIVE; > > > > COMMIT; > > > > is it roughly the same on the read-only (destination) side? in other words > > is: > > > > BEGIN EXCLUSIVE; > > > > COMMIT; > > > > the correct procedure? > > I think you will need to make sure that all SQLite instances have > closed the read-only database before copying over it. Otherwise all > the existing connections will continue to read the old data. > > Dan. This is very interesting. I got impression that the connections will figure out that they have new file (if it was overwrite and not move and copy) and just invalidate cache. Always ready to change the view :) . So the strategy could be to connect to database every so often, or even better to create adjoint database with one table like: create table version (version integer); and increment it in the same BEGIN/COMMIT scope. Then have your program check for version and reopen main database when needed Now I do have a question regarding BEGIN/copy/COMMIT process The BEGIN is made on the original database copy could be overwrite or rename old/copy new and COMMIT is made on the new database (or perhaps old if it was moved). How come there is no corruption of something here. It does not sound veery consistent from the perspective of a casual user. Can someone tell us what really happens in there, and what are possible ramifications. Thanks, Nikola - To unsubscribe, send email to [EMAIL PROTECTED] -
