Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
Tcl is really fine for web interfaces. Porting an almost 10 year old web application to sqlite2 and sqlite3 was a charme. It is supporting Linux, SunOS,Windows and maybe HP-UX so far. If you are interested in an generic example using SQLite 3.1.3 (but also supporting 2.1.16) look at http://softguard.dyndns.org:8015 or https://softguard.dyndns.org:8016 user is 'testIt' (uppercase i) password is '$4SBS' for unlimited access. Please clean up any changes you make after testing. As SQLite needs no further administration creating databases and tables on the fly is as simple as using the command line. You only need a standard tcl distribution, tclhttpd3.5.1 and sqlite/tclsqlite itself to run it. PS.: This site is only for demonstration and in work. Internationalization does only support English and German. Also cloning and copying records does not work so far. The API is still limited and mostly directed to msql2/3. Andrew Piskorski wrote: On Mon, Mar 07, 2005 at 04:22:50PM -0500, Eli Burke wrote: I qualify as opinionated, so: Tcl. The fact that Dr. Hipp supports Tcl directly for SQLite is yet another bonus. running apache although I'm open to alternatives. The app itself uses AOLserver. Among other things, it goes very nicely with Tcl.
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
APSW is not DBAPI compliant but it's close enough Note that I do document how APSW differs from DBAPI. http://www.rogerbinns.com/apsw.html#dbapinotes APSW is very nice. Thanks :-) I've used it and PySQLite and I'd recommend APSW. It's "thinner". Note that it is almost impossible to do a DBAPI compliant interface to SQLite. For example DBAPI requires providing time types which SQLite doesn't natively provide. A wrapper has to "fake" it. Similarly various transaction methods must be provided (commit, rollback etc) which are almost impossible to implement without sniffing the SQL. Also don't kid yourself about how easy it is to move from one DBAPI compliant system to another. Pretty much all projects provide their own layer as glue between their code and the DBAPI drivers. If you want DBAPI compliance then use pysqlite. It tries really hard to fill in the necessary pieces that SQLite doesn't have. On the other hand if you only want to use SQLite then use APSW. It doesn't hide anything and gives you full access to all SQLite functionality. You can also do things like define your own collations and functions in Python. Where applicable APSW does use DBAPI conventions and names. As for a web front end, I suggest you make an XML-RPC wrapper around your database and then access that from whatever you want to use for your web stuff. As an example of something I worked on in the past, I implemented a PHP front end using Smarty templates and a Python process on the backend which was talked at using XML-RPC. The Python process did everything including managing sessions and storing the templates. The PHP/Smarty code dealt with display. This let me use each environment for what they were best at and decoupled them. I could also have done other front ends such as a command line, which comes in really handy if you need to automate some processes. Roger
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
Eli, I'd highly recommend Python. I've used Perl, PHP and Python. Python is hands-down the winner. After getting ahold of the elegance of Python, PHP feels like a hack job. Perl is "executable line noise". Python is very mature and very nice. It has a far cleaner implementation of just about everything, especially OO than Perl and _way_ better than PHP. I would also avoid Microsoft specific technology like the plague. APSW is not DBAPI compliant but it's close enough that migrating to a bigger database (PostgreSQL, _not_ MySQL!) would not be difficult at all. APSW is very nice. I've used it and PySQLite and I'd recommend APSW. It's "thinner". You should look at www.cherrypy.org for a nice little web server written in Python to get you going. It's really slick. Check out Snakelets also (http://snakelets.sourceforge.net). I prefer CherryPy because Snakelets has a templating language that is too-closely bound to the web server. CherryPy 2.0 (beta currently but works well) unbound the templating language for the 2.0 release so you can use your own. I built my own templating language because I couldn't find one that I like out there. With Python you do have a LOT to choose from so it can be daunting. If you have experience with PHP then you've learned how to embed source code in HTML. This is not a very good idea. Separation of the logic and the presentation make for a cleaner design in my opinion. Some would debate this but it's Ok if they're wrong! :) I'll be happy to chat with you. You can find me on Jabber at [EMAIL PROTECTED] Cordially, Scott On Monday 07 March 2005 01:22 pm, Eli Burke wrote: > I've been working on a project using sqlite3 since last fall. At the time, > I knew that it would need a web-based front-end eventually. I have a very > small bit of experience with PHP, and I assumed that PHP would support > sqlite3 sooner or later. Well, it's later, and as far as I know, PHP > is still using the 2.x branch. > > So, I was wondering if any of the more opinionated among you would care > to suggest an interface language. It'll be on a Linux box, presumably > running apache although I'm open to alternatives. The app itself uses > sqlite3 for scheduling jobs and storing job data, so the web interface > only needs to be able to insert some data and do visualization > (pretty standard stuff I think). > > Ease of learning is a plus as I need to get something basic up and > running fairly fast. I've heard good things about Python in that respect. > Does anyone have alternative suggestions, or if you agree that Python Is > Good, would you suggest using APSW, pysqlite, or something else? > > Thanks, > Eli
[sqlite] Does "PRAGMA empty_result_callbacks = 1" work with APSW and 3.1.3?
[ Sorry - previous emal had the wrong pragma in two places (but the right one
in the code sample so I don't feel quite so dumb. It seems from the sqlite
docs that I should be getting different results than I am:
PRAGMA empty_result_callbacks;
PRAGMA empty_result_callbacks = 0 | 1;
Query or change the empty-result-callbacks flag.
The empty-result-callbacks flag affects the sqlite3_exec API only. Normally,
when the empty-result-callbacks flag is cleared, the callback function
supplied to the sqlite3_exec() call is not invoked for commands that return
zero rows of data. When empty-result-callbacks is set in this situation, the
callback function is invoked exactly once, with the third parameter set to 0
(NULL). This is to enable programs that use the sqlite3_exec() API to
retrieve column-names even when a query returns no data. ]
I'm using APSW 3.0.8-r3 on Python Windows XP Pro with Python 2.3.4.
Minimal test-case code:
import apsw
db = apsw.Connection('test.db3')
cursor=db.cursor()
cursor.execute('PRAGMA empty_result_callbacks = 1')
sql="select * from testnn" # testnn is empty
cursor.execute (sql)
description = cursor.getdescription()
Results:
Traceback (most recent call last):
 File "test_pragma.py", line 7, in ?
  description = cursor.getdescription()
apsw.ExecutionCompleteError: Can't get description for statements that
have completed execution
Am I doing something wrong here? ÂI'm expecting a description even
though the table is empty because the empty_result_callbacks pragma is on.
TIA,
Scott
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
On Mon, Mar 07, 2005 at 04:22:50PM -0500, Eli Burke wrote: > Ease of learning is a plus as I need to get something basic up and > running fairly fast. I've heard good things about Python in that respect. > Does anyone have alternative suggestions, or if you agree that Python Is > Good, would you suggest using APSW, pysqlite, or something else? Python is not bad, and you only have APSW and pysqlite to choose from. OTOH, the number of web frameworks in/for Python probably rivals the number of available Linux distros... http://www.python.org/moin/WebProgramming http://www.python.org/moin/WebStack HTH. -- Ng Pheng Siong <[EMAIL PROTECTED]> http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
Eli Burke wrote: I've been working on a project using sqlite3 since last fall. At the time, I knew that it would need a web-based front-end eventually. I have a very small bit of experience with PHP, and I assumed that PHP would support sqlite3 sooner or later. Well, it's later, and as far as I know, PHP is still using the 2.x branch. So, I was wondering if any of the more opinionated among you would care to suggest an interface language. It'll be on a Linux box, presumably running apache although I'm open to alternatives. The app itself uses sqlite3 for scheduling jobs and storing job data, so the web interface only needs to be able to insert some data and do visualization (pretty standard stuff I think). Ease of learning is a plus as I need to get something basic up and running fairly fast. I've heard good things about Python in that respect. Does anyone have alternative suggestions, or if you agree that Python Is Good, would you suggest using APSW, pysqlite, or something else? Since noone has mentioned it yet, I'd suggest Brainfuck (http://www.muppetlabs.com/~breadbox/bf/). Very easy to learn (only eight instructions) so you should have something up and running pretty quickly. Notably, it has some of the most elegant code structure I've ever seen. HTH. -- Richard Heyes
[sqlite] Assert with sql 2.6.8....
I am getting this assert when I call my sqlite from a c++ program... i have if def for c extern all of the files and everything compiles... but I get this error... main.c Assert (iDb>=0 && iDbnDb)failed in file ../../sqlite/src/build.c at line 2154 Anybody have any ideas... what my problem is. Tezozomoc.
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
On Mon, 2005-03-07 at 21:12 -0500, Andrew Piskorski wrote: > On Mon, Mar 07, 2005 at 04:22:50PM -0500, Eli Burke wrote: > > > So, I was wondering if any of the more opinionated among you would care > > to suggest an interface language. It'll be on a Linux box, presumably > > I qualify as opinionated, so: Tcl. The fact that Dr. Hipp supports > Tcl directly for SQLite is yet another bonus. > FWIW, the SQLite website uses TCL for scripting. (To be fair, most of the SQLite website is either static content or C code implementing CGI. But there are some scripts and they are all TCL.) -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
On Mon, Mar 07, 2005 at 04:22:50PM -0500, Eli Burke wrote: > So, I was wondering if any of the more opinionated among you would care > to suggest an interface language. It'll be on a Linux box, presumably I qualify as opinionated, so: Tcl. The fact that Dr. Hipp supports Tcl directly for SQLite is yet another bonus. > running apache although I'm open to alternatives. The app itself uses AOLserver. Among other things, it goes very nicely with Tcl. > Does anyone have alternative suggestions, or if you agree that Python Is > Good, would you suggest using APSW, pysqlite, or something else? People I trust are of the opinion that Python is a Good Thing, but I know nothing about one of its db APIs vs. another. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
Re: FW: [sqlite] patch for sqlite 3.1.3 to let 'make doc' work
On Mon, 7 Mar 2005 17:30:07 -0500 "Griggs, Donald" <[EMAIL PROTECTED]> wrote: > Hi Gerald, > > I don't think attachments are allowed on the list. Thank you, I noticed it only now. > You may want to check > the contributions section of the wiki, or perhaps the version tracking > system. I prefere email, everything else is too much work ;). The patch is very small so you will find it at the end of this mail. > Also, you might want to let folks know what operating system you're > talking about, since there are several. The patch is for linux. Gerald --- sqlite-3.1.3/Makefile.in.orig 2005-03-07 22:56:04.833954328 +0100 +++ sqlite-3.1.3/Makefile.in2005-03-07 22:56:41.189427456 +0100 @@ -451,6 +451,9 @@ arch.html: $(TOP)/www/arch.tcl tclsh $(TOP)/www/arch.tcl >arch.html +arch.png: $(TOP)/www/arch.png + cp $(TOP)/www/arch.png . + arch2.gif: $(TOP)/www/arch2.gif cp $(TOP)/www/arch2.gif .
[sqlite] patch for sqlite 3.1.3 to let 'make doc' work
attached a patch to let 'make doc' work Gerald
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
I strongly suggest to use pysqlite. APSW may be more powerfull in some areas but is not complaint with the python standard DB access API. If you will use pysqlite: 1) you will learn Python standard DBAPI 2) you will able to easly (relativly) migrate to another DB engine in future (mysql, postgresql, oracle...). Best regards, Witold Ease of learning is a plus as I need to get something basic up and running fairly fast. I've heard good things about Python in that respect. Does anyone have alternative suggestions, or if you agree that Python Is Good, would you suggest using APSW, pysqlite, or something else? Thanks, Eli
Re: [sqlite] thoughts on a web-based front end to sqlite3 db?
I suggest using a Perl 5.8 based solution. Perl is very mature and has strong SQLite 3 support in its extensions (DBD::SQLite). This will run on anything. It also isn't dependent on Microsoft technology. There are a number of pre-existing solutions on CPAN and elsewhere that you can look at for ideas, or for customizing. -- Darren Duncan At 4:22 PM -0500 3/7/05, Eli Burke wrote: I've been working on a project using sqlite3 since last fall. At the time, I knew that it would need a web-based front-end eventually. I have a very small bit of experience with PHP, and I assumed that PHP would support sqlite3 sooner or later. Well, it's later, and as far as I know, PHP is still using the 2.x branch. So, I was wondering if any of the more opinionated among you would care to suggest an interface language. It'll be on a Linux box, presumably running apache although I'm open to alternatives. The app itself uses sqlite3 for scheduling jobs and storing job data, so the web interface only needs to be able to insert some data and do visualization (pretty standard stuff I think). Ease of learning is a plus as I need to get something basic up and running fairly fast. I've heard good things about Python in that respect. Does anyone have alternative suggestions, or if you agree that Python Is Good, would you suggest using APSW, pysqlite, or something else? Thanks, Eli
RE: [sqlite] thoughts on a web-based front end to sqlite3 db?
I would shoot first with ASP.NET and make it portable to MONO for linux. PHP technology was eclipsed in speed of development and in use when .NET came out. I have done both. When I say both I have utilized both technologies as the head of the project and the coder at different times. Their is so much propoganda going around these days about which one is better or cheaper etc. I bet on .NET for install base and cost reasons but that does not mean I dno't have a special place in my heart for linux and all computers. I just like programming and computing in general from the having fun side. But from a business perspective, .NET on Windows is the way to go. Allan - Original message - From: [EMAIL PROTECTED] (Eli Burke) Date: 3/7/2005 3:14:50 PM Subject: [sqlite] thoughts on a web-based front end to sqlite3 db? > I've been working on a project using sqlite3 since last fall. At the time, > I knew that it would need a web-based front-end eventually. I have a very > small bit of experience with PHP, and I assumed that PHP would support > sqlite3 sooner or later. Well, it's later, and as far as I know, PHP > is still using the 2.x branch. > > So, I was wondering if any of the more opinionated among you would care > to suggest an interface language. It'll be on a Linux box, presumably > running apache although I'm open to alternatives. The app itself uses > sqlite3 for scheduling jobs and storing job data, so the web interface > only needs to be able to insert some data and do visualization > (pretty standard stuff I think). > > Ease of learning is a plus as I need to get something basic up and > running fairly fast. I've heard good things about Python in that respect. > Does anyone have alternative suggestions, or if you agree that Python Is > Good, would you suggest using APSW, pysqlite, or something else? > > Thanks, > Eli > >
[sqlite] thoughts on a web-based front end to sqlite3 db?
I've been working on a project using sqlite3 since last fall. At the time, I knew that it would need a web-based front-end eventually. I have a very small bit of experience with PHP, and I assumed that PHP would support sqlite3 sooner or later. Well, it's later, and as far as I know, PHP is still using the 2.x branch. So, I was wondering if any of the more opinionated among you would care to suggest an interface language. It'll be on a Linux box, presumably running apache although I'm open to alternatives. The app itself uses sqlite3 for scheduling jobs and storing job data, so the web interface only needs to be able to insert some data and do visualization (pretty standard stuff I think). Ease of learning is a plus as I need to get something basic up and running fairly fast. I've heard good things about Python in that respect. Does anyone have alternative suggestions, or if you agree that Python Is Good, would you suggest using APSW, pysqlite, or something else? Thanks, Eli
Re: [sqlite] what is "in-memory SQLite database"?
Naming the database ':memory:' (without the quotes) will not create a file but place the database in memory. Needless to say - it will not remember tables created their after disconnection, and will use RAM up :-) Eddy jack wu wrote: in the documentation: "Appropriate Uses For SQLite" it says: "it is often easier and quicker to load the data into an in-memory SQLite database and use queries with joins and ORDER BY clauses to extract the data in the form and order needed rather than to try to code the same operations manually" i am wondering if there are more information/documentations on how to do that? i am writing an application where i need to define couple of huge hash tables. i load the data from disk, populate the hash tables and use the tables during execution. can i replace the hash tables using SQLite? i am new to SQLite, so any information is helpful. jack.
Re: [sqlite] Does sqlite has isnull function?
[EMAIL PROTECTED] wrote: FYI: The function, as defined in ANSI, you are looking for is COALESCE select COALESCE(MAX(SubOrder), 0)+1 from Table1 where ... This is supported in sqlite3 (and I guess sqlite2) Eddy What I want to do is: select ISNULL(MAX(SubOrder), 0)+1 from Table1 where ... anyway I can do this, since isnull is not working this way. Thanks,
Re: [sqlite] SQLite3 and thread safety
What Platform are you on? For UNIX platforms there may be a problem, see the comments in the os_unix.c file in the source directory, or here http://www.sqlite.org/cvstrac/getfile/sqlite/src/os_unix.c?v=1.41 Though reading through things, wrapping arounb a MUTEX should be OK so long as there are no outstanding transactions (ie - you commit after inserting/updating/deleting a row and before releasing the mutex). Also - under UNIX - if you are wrapping it around a MUTEX, you may want to do a "pthread_cond_wait" instead (or as well I should say) as that is cancellable should the thing hang. Eddy Cory Nelson wrote: I understand you are supposed to open a new sqlite3 connection for every thread that needs access, but- would it be safe to wrap access to the database with a mutex? I've got code that needs to insert at random times (sometimes many times per sec) and select once per sec in another thread. The inserting can really get to CPU usage so i want to wrap it in a transaction that is closed/opened every time the select is performed. If there is a better way, I'm open to that too :)
Re: [sqlite] pragma table_info
On Sun, 2005-03-06 at 23:36 -0800, Charles Mills wrote: > Is there anyway to do 'pragma table_info' on a table in an attached > database (even if a table in the main database has the same name). I > guess I am wondering why this doesn't work: > PRAGMA table_info(database_name.table_name) > > I get 'near ".": syntax error'. > PRAGMA database_name.table_info(table_name); -- D. Richard Hipp <[EMAIL PROTECTED]>
