Re: [sqlite] aces a databases store into a web server not into my local PC
Le vendredi 21 décembre 2007, finder a écrit : > Hi, > I don't find how to aces a databases store into a web server, > throught a web page. > I want to make a form that post a query and receive the result > using a web page. > > Many thanks You could use a php script using the PDO::SQlite interface... - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] [Linux + PHP] Recommended way to access SQLite?
Le dimanche 9 décembre 2007, Gilles Ganault a écrit : > It seems like I have two options: > - calling the SQLite library > - going through the PDO interface, and its SQLite module. > > Which of the two would you recomend? Are there other options I > should know about? I would recommend using PDO interface, as this is the standard PHP5 API. Don't worry about PHP4, as this old version will no more be supported soon... - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] SQLite Path Problem On Fedora Core 5
Robert L Cochran a écrit : > However, on Fedora Core 5, my path is set so that objects on > /usr/local/bin are found before those on /usr/bin. I'm not sure how this > is happening; perhaps /etc/profile? The result seems to be that even if > sqlite 3.3.3 was installed by yum, executing /usr/bin/sqlite3 will yeild > a command line stating its version is 3.2.7 which is one of the > versions I believe I installed to /usr/local myself. Yes FC5 uses the following default path: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin which means your binaries in /usr/local/bin will be accessed before those in /usr/bin. > How do I fix my sqlite version mess so that I can have multiple > installed versions: the one used by yum (and possibly other modules) and > the latest and greatest release, which I want to link into PHP for my > own purposes. (Yes I compile PHP on my own.) With an up to date yum install, FC5 default SQlite is 3.3.3 You can clean up thethings in the following way. Instaed of using /usr/local for prefix when configuring a sqlite build you could pass: ./configure --prefix=/usr/local/sqlite-3.3.6 (for 3.3.6 version) This will install each of your multiple sqlite versions (except de default used by yum) in its own envronment. To build an application with a particular sqlite build, you'll have to add, ie for PHP 5.1.4: --with-sqlite=/usr/local/sqlite-3.3.6 --with-pdo-sqlite=/usr/local/sqlite-3.3.6 As PHP configuration system uses the --rpath which tells the binaries the full path of used libraries, this will work. For applications where you're not sure --rpath is used, you can add it to configure options.
Re: [sqlite] problem with creating a table
A. Pagaltzis a écrit : > * Bijan Farhoudi <[EMAIL PROTECTED]> [2006-06-25 17:05]: > >> A. Pagaltzis wrote: >> >>>.headers on >>>SELECT [order] FROM foo >>> >> But how would you know the name of the col is "order" not >> "[order]"? >> > > That’s what `.headers on` was supposed to demonstrate. > > Regards, > BTW, this just demonstrate one should never use standard SQL reserved words as column or table names :) Wouldn't it be a better strategy to rename this order column to something not reserved such as "ordering", "sorting" or anything else not being a resreved word.
Re: [sqlite] The fastest way to change the data of a table?
Alexei Alexandrov a écrit : > Hi, > > Basically, I need to do the following: given a big-big table, I need > to iterate through all its rows and change a column in about half the > rows. The contents of the column to change depends on other columns, > but only partially, so triggers won't work here. Well, this mainly depends on your database structure. If the column to change is indexed, a simple UPDATE some_table SET some_column=some_value_or_function_result WHERE some_condition can be quite fast. Otherwise you should use the EXPLAIN statement on the query to see what happens and is a time consumer. > What would be the fastest way to do it? I assume that you cannot just > do prepare/step and do updates while iterating over the table, right? > Remembering rowid-s for the rows to change can potentially eat all my > (well, computer's) memory, so it doesn't look perfect either. This also depends on what interface you use. Will it be C, C++ or PHP, Perl, Python ? PHP PDO_SQLite interface uses an object oriented syntax which allows pure SQL queries without thinking about prepare/step paradigm. It's very efficient, even on huge tables (more than 10 million records). > This task is solved pretty trivially and efficiently in dbf-based > simple databases (FoxPro, Codebase), but it seems to me that I'm just > missing something very basic about SQLite features. Dbf based databases have different paradigms than pure SQL based ones. When I deal with dbase syntax, I usually now use Clip, a Clipper compatible free system which allows SQL xBase queries.
Re: [sqlite] Wildcards
Alex Roston a écrit : > Ideally I'd like to do something like: > > "UPDATE card SET foo='100' where bar='ABC*';" > Use SQL standard construct: UPDATE card SET foo='100' WHERE bar LIKE 'ABC%' ;
Re: [sqlite] question about php_pdo_sqlite
yuyen wrote: > Ok, finally I found the problem is that the PHP and Apache are > installed in local drive and I put the sqlite database file on a > remote file server which is a Linux / Samba. I can use sqlite3.exe to > open that remote database with a mapped remote drive. And Insert, > Update and Delete have no problem with it. While with Apache and PHP > pdo, if the database is concurrently opened by sqlite3.exe, it will > report "can't not open database". Close sqlite3.exe, then PHP pdo can > open it, but it open as read-only. If I put the database file in local > dirve, then there is no any problem at all. Even I can use sqlite3.exe > concurrently with PHP pdo. Does Apache has different thinking about > remote server? > > Jack Did you fully read Apache documentation ? Maybe some RTFM can help with this. >From Apache doc, section Running Apache as a service on Windows: "By default, all Apache services are registered to run as the system user (the LocalSystem account). The LocalSystem account has no privileges to your network via any Windows-secured mechanism, including the file system, named pipes, DCOM, or secure RPC. It has, however, wide privileges locally." This explains the problem you face. Apache is more secured than most Windows services. There is a simple solution which will give you write access to your remote file system: Create a separate account for running Apache services. This is mandatory to access network resources. Simple steps: 1. Create a normal domain user account, and memorize (write doiwn) its password. 2. Grant the newly created account a Logon privilege as a service and Act as part of the OS. You'll have to use Group Policy to propagate those settings. 3. Confirm the new account as a member of the Users Group 4. Grant this account Read and Execute rights to all documents and folders (including subfolders) in your Apache Root Directory (htdocs and cgi-bin) 5. Grant this account Change (RWXD) rights to Apache logs folder. 6. Grant the account Read and Execute (RX) rights to Apache binary. Then stop and restart Apache Services. You should have access to your network mounts, providing your scripts use the standard: \ instead of the classic :\\\ This should solve all of your access rights assignations between your PHP script, Apache and the network mount. If this can help, let us know :) JCR
Re: [sqlite] question about php_pdo_sqlite
yuyen wrote: > And the error message is: > "execute err: SQLSTATE[HY000]: General error: 8 attempt to write a > readonly database" > > So the problem is why the database becomes read only. > This time, you get another message :) Are you sure the Web Server user (Apache or...) has write access to your sqlite database file ?
Re: [sqlite] question about php_pdo_sqlite
yuyen wrote:
> HI, JC
> I use php_do_sqlite with PHP 5.1.4 and Sqlite 3.2.8 on Windows XP. The
> following is my coding:
>
> try{
> $dsn = 'sqlite:counter/cntdata.sq3';
> $myConn = new PDO($dsn);
> $myConn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
>
> $myPre = $myConn->prepare('update test_item set balqty = 100');
> $myPre->execute();
> }catch (PDOException $e){
> die('execute err: '.$e->getMessage());
> }
> print('done!');
> ?>
> -
> And the error is:
> execute err: SQLSTATE[HY000]: General error: 1 SQL logic error or
> missing database
>
> -
> Would you please have a look and give me an advise. Thank you!
>
>
> Jack
>
Not having a windows box at hand, I can only guess things :)
But, if I remember (and sounds like this in PDO code) dns is passed as
is, so for windows, your dsn should be:
$dsn = 'sqlite:counter\\cntdata.sq3';
or, if you want a really portable way:
$dsn = 'sqlite:counter' . DIRECTORY_SEPARATOR . 'cntdata.sq3';
JC
Re: [sqlite] question about php_pdo_sqlite
yuyen wrote: > Hi, all > > I try to use php_pdo_sqlite in php which is a sqlite of version 3.2.8. With > php_pdo, it provides PREPARE and EXECUTE functions to prepare an sql at first > then which can execute later. But it seems that the php_pdo_sqlite.dll > doesn't support it. Or I may do somthing wrong. If there is anyone who has > the experience, please give me an advice. Thank you! > > > Jack > Hi Jack, I use php_do_sqlite too, with PHP 5.1.4 and SQlite 3.2.8, Linux build. Prepare and Execute methods work well, but I remeber some problems with PHP 5.0.4 builds. JC
Re: [sqlite] Anyone knows any sqlite based bullettin board ?
Le mardi 2 Novembre 2004 09:36, George Ionescu a ÃcritÂ: > I'm looking for an sqlite-based bulletin board to run under linux. > Any recommendations? All PHP CMS, forum and boards using adodb php class can use sqlite. Google with sqlite cms -- JCR aka DJ Anubis LAB Project Initiator & coordinator
Re: [sqlite] SQLite for large bulletin board systems?
Le vendredi 27 Août 2004 23:30, D. Richard Hipp a écrit : > The best design would be to make the application generic so > that it could use either SQLite or a client/server database. > Then smaller sites could use SQLite and take advantage of > the reduce management and overhead it provides while larger > sites could use a client/server database for scalability. For PHP users, ADOdb library needs a glance, as its abstract engine is fast and really well designed. It has drivers for most databases (sqlite included) and an abstract XML schema for databases. -- JCR aka DJ Anubis LAB Project Initiator & coordinator
Re: [sqlite] Version 3.0.0 compiler warnings
Le samedi 19 Juin 2004 13:48, Daniel K a écrit : > To fix this you need a TCL upgrade. Any 8.4.* will Thanks. Maybe this could fix my make doc problem too. I use tcl-8.3.5 for now. I'll try an upgrade. -- JCR aka DJ Anubis LAB Project Initiator & coordinator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spam: Re: [sqlite] Version 3.0.0 ALPHA now available
Le samedi 19 Juin 2004 09:28, Hans-Juergen Taenzer a écrit : > But for example in the interface file sqlite(3).h there is not made > use of this typedef (or INT64_TYPE defined in sqliteInt.h): > > long long int sqlite3_value_int64(sqlite3_value*); try to patch as: INT64_TYPE sqlite3_value_int64(sqlite3_value*); or long long sqlite3_value_int64(sqlite3_value*); if this compiles, propose the typo change as a bug report. This could help improving portability. -- JCR aka DJ Anubis LAB Project Initiator & coordinator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Version 3.0.0 ALPHA first report
Le samedi 19 Juin 2004 08:34, Daniel K a écrit : > You mean the sqlite3_exec() enters an infinite loop > and never returns? If you get the chance, can you post > an example of SQL that causes this. Thanks. Sorry for the inconvenience. Problem solved running through gdb. This was a bug on mine. I had a circular trigger (trigger triggering another trigger which triggered the first one). Cleaning the trigger declaration solved it. -- JCR aka DJ Anubis LAB Project Initiator & coordinator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] the 2.8 database ananysis tool
Le samedi 19 Juin 2004 05:32, Steve Palmer a écrit : > I see versions of this for Linux and Windows, but not for Mac OSX. > Are the sources going to be made available so that we can build for > our platform? Should work for MacOS X. See os_mac.h comment ** This header file defines OS-specific features of classic Mac. ** OS X uses the os_unix.h file, not this one. Try to compile and tell us ;-) I can't try here as I have no Mac on hand. -- JCR aka DJ Anubis LAB Project Initiator & coordinator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spam: Re: [sqlite] Version 3.0.0 ALPHA now available
Le vendredi 18 Juin 2004 22:20, Hans-Juergen Taenzer a écrit : > I don't think there would be problems with the new version 3.0 if > there wasn't the problem with the 'long long' datatype. Just using > a suitable typdef for this datatype would resolve the problem > (maybe there have to be changes to printf() too, I haven't checked > it yet). It should compile with MSC as os_win.h already contains the needed definitions: #if defined(_MSC_VER) || defined(__BORLANDC__) typedef __int64 off_t; #else # if !defined(_CYGWIN_TYPES_H) typedef long long off_t; # if defined(__MINGW32__) # define_OFF_T_ # endif # endif #endif Maybe some defines checking needed. -- JCR aka DJ Anubis LAB Project Initiator & coordinator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Version 3.0.0 ALPHA first report
Built v3 on the following systems: Linux Fedora Core 1 on AMD Athlon XP 2800+ Linux Mandrake 10 on a dual PIII 700 Linux RHE 3 on a dual Itanium 2 box. the make doc should be revised, as common.tcl is no more in package. Checked all of this using a script generating a database with 100 tables, some of them huge. Database is roughly 10 gigas. New btree code sounds efficient enough to compete with MySQL on queries providing BLOBs are relegated to the last columns. Inserts have been improved from 2.8, even on large sets. Concurrent inserts by 20 processes sound smooth. However, trigger.c might need some optimizations, as we can end up with endless triggerings when using somewhat complex queries. I'll make more tests during the week end and provide a full report, with platform independant C++ test code. Thanks for the improvements. Great job +++ -- JCR aka DJ Anubis LAB Project Initiator & coordinator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Is there a demand for Client / Server Modules ?
Le jeudi 17 Juin 2004 16:20, Alex K a écrit : > Is there any demand for this ??? Sure, if you already developed it, I will not have to reinvent. If I can help for the linux port, tell me. -- JCR aka DJ Anubis LAB Project Initiator & coordinator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
