Re: [sqlite] Get Max Samples
On Tue, 10 Nov 2009 15:28:30 -0500, Pavel Ivanov wrote: > You're right about max() and group_concat() will not help you either. > You need something like this: > > select max(cnt) > from (select count(*) as cnt from table_name group by SampleNum) That'll give you the count of the largest set. But not the actual value. For that you need to combine it with a HAVING clause. But I'll leave that as an exercise :-) Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Does PRAGMA synchronous=OFF ensure that no synching is done for the entire session?
On Mon, 17 Aug 2009 10:47:23 -0400, Angus March wrote: >> Because yes, that's what synchronous=OFF means. It stops SQLite from >> issuing fflush calls (effectively). >> > Right, and this is implied by the documentation, but I was concerned > that the documentation might be playing fast and loose, saying that > fflush (or fsync, or fdatasync) won't be called, when it really means > that it won't be called during any call to step() or finalize(), while > it would be called when the session is closed. I wasn't sure, so I > thought I'd ask, because it'll matter to my app. Kernels will fflush when a file handle is closed, which will happen when you close the database handle. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Does PRAGMA synchronous=OFF ensure that no synching is done for the entire session?
On Fri, 14 Aug 2009 12:33:30 -0400, Angus March wrote: > I want my INSERT done right away, I just don't want it to be flushed > from the filesystem's write-behind cache until the kernel decides, not > when SQLite decides. Did you mean you do "want it to be flushed from the filesystem's write-behind cache when the kernel decides (rather than when SQLite decides)"? Because yes, that's what synchronous=OFF means. It stops SQLite from issuing fflush calls (effectively). __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite3 immune from injection attacks if file is readonly?
On Sat, 18 Jul 2009 10:17:14 -0700, Kelly Jones wrote: > On a website, I want to take a user's query "as is", save it to a > userquery.txt, and then do: > > sqlite3 /path/to/mydb < userquery.txt > > where /path/to/mydb is a *read-only* file. > > Is there *any* risk of an injection attack here? Yes. Massively. You need to read up on the fundamentals of SQL injection, and use a proper API for accessing the DB that allows you to use bind variables. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Performance against huge datasets
On Tue, 23 Jun 2009 22:01:26 +0200, Misza wrote: > I wonder if anyone used SQLite extensively with big datasets and could > provide some insight into performance? > In a nutshell, I am writing an ETL framework and need a good (read: > performing) engine for the "T"ransform part. > I suppose I could use flat files for that, but I'd like to have some SQL > capabilities at my disposal, which is why I'm poking around file-based, > serverless engines. > The question is, how does SQLite perform when faced with huge datasets, > where "huge" means 10s of gigabytes in size (typical for a Data > Warehouse's staging area)? > Most common operations (after unload) would include multi-table joins > (mostly merge joins), field transformations (contatenation, casting) and > record filtering. You might want to consider Hive. http://www.facebook.com/note.php?note_id=89508453919 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] speeding up row by row lookup in a large db
On Sat, 21 Mar 2009 23:42:30 +0100, Stefan Evert wrote: > On 21 Mar 2009, at 15:31, P Kishor wrote: > >> I did some benchmarking with the above schema using Perl DBI, and I >> get about 30 transactions per second as long as I returning the data >> to memory. > > Even for Perl/DBI, that seems pretty slow. Depends on how much data > each of these transactions returns, though -- if there are thousands > of rows in lc or dist for each cell_id, then you can't expect much > better performance. Even though DBI and DBD::SQLite are written in C, > they have to allocate fairly complex data structures to return the > data (in the best case, an anonymous array with 40 to 60 entries for > each data row in the result set), and these operations are relatively > expensive in Perl (I know because I've written some XS code recently > that does this kind of thing). Perl DBI doesn't do this though. It allocates one array and re-uses it for every row. This makes it very fast. The perl DBI test suite does some benchmarking. Last time I built DBI it could do easily over 10k result rows per second. > Another thing to keep in mind is that the SQLite version included in > the DBD::SQLite distribution is fairly old (3.4.0 on my Mac -- I doubt > there's a more recent version of DBD::SQLite around), and AFAIK there > have been some speed improvements in SQLite recently. There should be a way to update it. Either use DBD::SQLite::Amalgamation from CPAN and update the amalgamation file, or run the getsqlite.pl script before compiling (not sure if that works any more though - it's fairly picky about how the tarball is built). > (Darren, any news from the maintainer of DBD::SQLite? I would be very > delighted and grateful to be able to use an up-to-date SQLite version > in my Perl scripts.) I'm here, I'm just very slow. I did try and pass it off to someone else as maintainer but they vanished. No idea why. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] configure syntax error on HP
On Sat, 21 Jun 2008 11:50:31 +0700, Dan wrote: > >> On Thu, 19 Jun 2008 12:05:56 -0400, D. Richard Hipp wrote: >>> >>> On Jun 19, 2008, at 11:49 AM, Matt Sergeant wrote: >>>> >>>> Note that there are some C++ style comments crept back into the code >>>> (I >>>> noticed in the amalgamation, so I can't give you a direct pointer to >>>> them). This causes compile failures on stricter C compilers. >>> >>> >>> Already been fixed. http://www.sqlite.org/cvstrac/chngview?cn=5207 >>> and http://www.sqlite.org/cvstrac/tktview?tn=3172 >> >> Good. You might want to consider adding a test for this - my >> DBD::SQLite does one, but I'd rather you catch things upstream. > > How do you test this? Effectively a grep for '//' minus those matching http://. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] configure syntax error on HP
On Thu, 19 Jun 2008 12:05:56 -0400, D. Richard Hipp wrote: > > On Jun 19, 2008, at 11:49 AM, Matt Sergeant wrote: >> >> Note that there are some C++ style comments crept back into the code >> (I >> noticed in the amalgamation, so I can't give you a direct pointer to >> them). This causes compile failures on stricter C compilers. > > > Already been fixed. http://www.sqlite.org/cvstrac/chngview?cn=5207 > and http://www.sqlite.org/cvstrac/tktview?tn=3172 Good. You might want to consider adding a test for this - my DBD::SQLite does one, but I'd rather you catch things upstream. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] configure syntax error on HP
On Wed, 18 Jun 2008 19:58:02 -0400, D. Richard Hipp wrote: > > On Jun 18, 2008, at 7:12 PM, Andrea Connell wrote: > >> I want to use the C API with a C++ class but when I try compiling... >> >> $ aCC -AA +W829 main.cpp sqlite3.c >> main.cpp: >> sqlite3.c: >> Error 482: "sqlite3.c", line 532 # Array of unknown size; 'const char > > SQLite is written in C, not C++. You have to use a C compiler to > compile it. If you compile to object code, you can normally link it > against C++ code without difficulty. But you cannot compile SQLite > directly using a C++ compiler. Note that there are some C++ style comments crept back into the code (I noticed in the amalgamation, so I can't give you a direct pointer to them). This causes compile failures on stricter C compilers. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] database permanently locked
On 3-Dec-06, at 7:24 AM, [EMAIL PROTECTED] wrote: Max Barry <[EMAIL PROTECTED]> wrote: My database is permanently locked, and I've spent two fruitless days trying to unlock it. The problem: $ sqlite trac.db SQLite version 3.3.6 Enter ".help" for instructions sqlite> .databases Error: database is locked Is the database on an NFS filesystem. The locking is busted on some (many?) implementations of NFS, resulting in behavior like shown above. Make sure you're running nfslockd. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite driven web-site
FWIW I've created a very high traffic web site (over 2000 tps) that uses SQLite at its core (also uses MS SQL Server, but don't blame me for that). So high traffic isn't a problem with a good design. On 5-May-06, at 11:30 AM, Clark Christensen wrote: I have dynamic apps running on my company's website using Perl and SQLite. There's a very good wrapper for using SQLite with the Perl DBI. Check out http://search.cpan.org/~msergeant/DBD-SQLite-1.12 It works well for a low-volume app on a public site. I'm working on a new app (also all Perl) now that'll be sending considerably more traffic to the SQLite database (more frequent reads and writes), plus session management. We'll see how that goes, but I'm not expecting problems beyond occasional locks. -Clark - Original Message From: "Rajan, Vivek K" <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Thursday, May 4, 2006 10:29:18 PM Subject: [sqlite] sqlite driven web-site Dear SQLite community- I want to develop a dynamic web-site (for small group of people < 5-10). For this I am thinking of using SQLite. Couple of questions: * Are there some docs and/or package available to do something like this? * I would like to use perl as the programming interface - this is most what I am familiar with Has someone done something like that and would share their experience on this topic. Vivek __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Direct use of SQLite btree functions / performance
On 20-Apr-06, at 9:10 AM, Jay Sprenkle wrote: Just out of curiosity why is this data in the database? I've seen very few applications where the blob is indexed or operated upon by the database and it's always a pain to deal with it. We always just left binary data in the file system and stored references to it in the database. I just have to backup one file :-) __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] File locking additions
On 7-Mar-06, at 7:06 PM, Adam Swift wrote: In order to provide locking support for database files mounted from remote file systems (NFS, SMB, AFP, etc) as well as provide compatible locking support between database clients both local and remote, I would like to propose some additions to the existing database file locking behavior. I definitely like all the things you've proposed. We currently use SQLite over NFS (to a NetApp) and while it mostly works, we do occasionally get locking issues that I'd love to be able to get rid of. To those who have said "create a server" this simply isn't possible on an appliance NFS server. URIs will allow us to do something like ?mkdir=1 to specify that if the directory didn't exist to make it first. Very handy. Matt.
Re: [sqlite] DBD::SQLite bug number 17292 - bounty!
On 28 Jan 2006, at 01:09, Randy J. Ray wrote: Although - now that I've said all that - does the dbd interface actually use sqlite3, or just version 2? DBD::SQLite uses sqlite3. Correct. There's DBD::SQLite2 for those who have to use sqlite2 for legacy purposes, but I'm pretty sure it isn't being maintained. Incorrect. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] problem with blobs (perl code)
On 5 Dec 2005, at 13:23, [EMAIL PROTECTED] wrote: I added a test case (check-in [2798]) that checks to make sure that sqlite3_result_text is able to deal with embedded '\000' characters in a string. I appears to work fine. I cannot reproduce the problem Can you suggest other ways of producing the problem? Not yet. Let me write a test case and see if there's really a bug or not. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] problem with blobs (perl code)
On 2 Dec 2005, at 13:07, [EMAIL PROTECTED] wrote:
Right. So it's retreival that's the issue when this occurs, because I
do:
int col_type = sqlite3_column_type(stmt, i);
and it returns SQLITE_TEXT, so I then do:
val = (char*)sqlite3_column_text(stmt, i);
which doesn't return a length for me.
Would sqlite3_column_bytes() return the right length there rather than
me doing strlen() on the resulting data?
yes it will.
OK, so 1.11 is on CPAN which fixes this. However I have another bug
report about this not working for user defined functions, where I do
this:
s = SvPV(result, len);
sqlite3_result_text( context, s, len, SQLITE_TRANSIENT );
(SvPV is a macro that retrieves a char* from result, and as a side
effect sets len to the length of the string in bytes, even if it
contains nuls).
Is this maybe a bug in sqlite3_result_text()? I could patch it to do:
if (memchr(s, 0, len)) {
/* if the result contains NUL(s) treat it as a blob */
sqlite3_result_blob(context, s, len, SQLITE_TRANSIENT );
}
else {
sqlite3_result_text( context, s, len, SQLITE_TRANSIENT );
}
But that seems a waste of resources if it's a bug in
sqlite3_result_text().
Matt.
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: [sqlite] problem with blobs (perl code)
On 2 Dec 2005, at 08:07, [EMAIL PROTECTED] wrote: Would sqlite3_column_bytes() return the right length there rather than me doing strlen() on the resulting data? yes it will. Doh! In that case then 1.11 will head to CPAN with blobs working transparently. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] problem with blobs (perl code)
On 1 Dec 2005, at 21:52, [EMAIL PROTECTED] wrote: SQLite does has a separate BLOB type. But for TEXT types, SQLite still works like Perl and carries around a length so that the string can have embedded '\000' characters. I just added a test to the test suite to verify that this works. Suppose you do this: sqlite3_bind_text(pVm, 1, "abc\000xyz\000pq", 10, SQLITE_STATIC); If this is part of an INSERT, say, then you will insert a 10-character string that happens to contain a couple of extra \000 characters. Right. So it's retreival that's the issue when this occurs, because I do: int col_type = sqlite3_column_type(stmt, i); and it returns SQLITE_TEXT, so I then do: val = (char*)sqlite3_column_text(stmt, i); which doesn't return a length for me. Would sqlite3_column_bytes() return the right length there rather than me doing strlen() on the resulting data? Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] problem with blobs (perl code)
On 1 Dec 2005, at 15:10, [EMAIL PROTECTED] wrote: So in the example of $sth->execute($blob), if $blob contains an integer, use sqlite3_bind_int64(), or if $blob contains a string use sqlite3_bind_text(), or if $blob contains a blob, then use sqlite3_bind_blob(), and so forth. Is there something about perl internals that prevents the above from working? Yes. Perl has no concept of blobs. A scalar variable can be one of: IV (integer) UV (unsigned integer) NV (double) PV (string) so a blob is just a string - but perl carries a length around with it so you can have binary data in there. You'd have to check something like strlen(data) != len to determine if it contained NULs (or just scan for the NUL - same difference). Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] problem with blobs (perl code)
On Thu, 1 Dec 2005, Matt Sergeant wrote: > > Looking now at the DBI documentation, I see that values bound using > > execute are 'usually treated as "SQL_VARCHAR" types unless the driver > > can determine the correct type (which is rare)'. Because it is simple > > to scan the string for NUL's, I guess I consider this one of those > > rare cases where the driver can just 'do the right thing'. > > It's pointless though to do that, because then when they try and get data > out the same way they won't understand why it's truncated. At least this > way they have to bind properly on both in and out. Oh, I forgot to answer the issue - if I did a scan for NUL bytes on every string going into the system it would really hurt those doing performance sensitive apps. Unfortunately for you that includes me :-) Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Request for comment: Proposed SQLite API changes
On 3 Nov 2005, at 08:18, [EMAIL PROTECTED] wrote: As currently implemented, when an error occurs during sqlite3_step(), the function returns SQLITE_ERROR. Then you have to call either sqlite3_reset() or sqlite3_finalize() to find the actual error code. Suppose this where to change in version 3.3.0 so that the actual error code was returned by sqlite3_step(). That would mean that moving from version 3.2.7 to 3.3.0 might involve some minor code changes. The API would not be 100% backwards compatible. But the API would be cleaner. What does the community think about such a change? Changing backwards compatibility considered very bad by me. What a mess that would be for DBD::SQLite if/when someone updates sqlite.so and everything stops working in very subtle ways. Yuck! Wrap it in a new function please. Another proposal: Suppose that when creating an sqlite3_stmt using sqlite3_prepare, the original SQL text was stored in the sqlite3_stmt. Then when a schema change occurred, the statement was automatically recompiled and rebound. There would no more SQLITE_SCHEMA errors. But sqlite3_stmts would use a little more memory. And sqlite3_step might take a little longer to initialize sometimes if it found it needed to rerun the parser. What about this change? Is it a worth-while tradeoff? Judging by the followup you posted this can't be done easily, but I'd be happy if you can find a way. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Does SQLite have a fulltext search like MySQL?
On 5 Jul 2005, at 17:48, Michael Grice wrote: If not, are there plans to add this? What language are you planning to use? Perl has a bunch of full text search modules that implement FTS on top of any DB. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Quick news on the Perl-bindings front
On 21 Jun 2005, at 15:41, Darren Duncan wrote: At 1:29 PM -0400 6/21/05, Matt Sergeant wrote: 1.09 is now on CPAN. Note that there's a weird bug when trying to compile against the system sqlite on OS X Tiger due to some munging Apple have done to the header files. Someone is supplying me with a work-around. I noticed that upload before seeing this post; thanks. Can you please say which file(s) you changed to implement the (don't turn looks-like into numbers unless asked) change, mentioned in the changelog? When I used CPAN's diff utility and looked at the files which seemed to be specific to DBD::SQLite, other than the Makefile.PL, I didn't see any changes in them besides version number updates. I looked in SQLite.xs and SQLite.pm. It's all just magic in Makefile.PL - telling perl which files to compile (or not) and link against (or not). Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Quick news on the Perl-bindings front
On 20 Jun 2005, at 06:57, Randy J. Ray wrote: I just sent a patch to the maintainer of the DBD::SQLite package, that lets it build against an installed version of the library. The current package carries a copy of the code with it, and builds it locally. With this patch, you can update your base sqlite installation and the Perl driver will stay in sync. Not sure about the maintainer's schedule, but I imagine we'll see a release in the next few days. 1.09 is now on CPAN. Note that there's a weird bug when trying to compile against the system sqlite on OS X Tiger due to some munging Apple have done to the header files. Someone is supplying me with a work-around. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] preventing text to integer conversion of bind variables in perl
On 15 Jun 2005, at 17:02, Jonathan H N Chin wrote: So perhaps the check no longer performs a useful function now that sqlite allows one to specify the data type of the column? Perhaps indeed. I think I'll remove it from the next release. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] preventing text to integer conversion of bind variables in perl
On 15 Jun 2005, at 11:56, Jonathan H N Chin wrote:
I would be interested to know what version of DBD::SQLite Puneet Kishor
is using, since I believe I have tracked the issue to a test in
the sqlite_st_execute() function in dbdimp.c :
else if (looks_like_number(value)) {
/* bind ordinary numbers as numbers - otherwise we might sort
wrong */
retval = sqlite3_bind_double(imp_sth->stmt, i+1, SvNV(value));
}
This test appears in all the versions of DBD::SQLite that I can find
and appears to be what causes the text to be treated as a number.
Does this check actually perform any useful function (as per the
comment)
or will it be safe to delete it?
I added it because of another bug report that was incorrectly sorting
integer columns based on text sort order. For example if you inserted:
("k1", 8);
("k2", 9);
("k3", 10);
("k4", 11);
and then asked for: SELECT * FROM t ORDER BY Column2
you get back:
k3, 10
k4, 11
k1, 8
k2, 9
Which seems obviously incorrect.
To be honest I'm not entirely sure what the correct fix is - maybe
ignore the above bug and tell the requestor he has to: SELECT * FROM t
ORDER BY int(Column2)
In answer to your question though, yes you can remove that bit of code,
as long as you're aware of the above side effect.
Matt.
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: [sqlite] DBD-SQLite build query
On 28 Apr 2005, at 17:53, Clark Christensen wrote: For what it's worth, it looks like getsqlite.pl hasn't been updated in quite some time. It gets the package just fine, but it extracts the archive using the archive's embedded dirnames, then changes directory to 'sqlite', at which point, the rest of the script fails. It's not that getsqlite.pl isn't updated, it's that Mr Hipp keeps changing how he formats/stores his package :-) You'll see some version checks in there from when it was last changed. Guess it needs updating again. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Reading Database Schema Info. in Perl
On 30 Mar 2005, at 04:05, [EMAIL PROTECTED] wrote: I need to be able to read all table names in the database, and further all attribute names in each table. ( am using DBD::SQLite in Perl) For gathering all the table names I've used the sqlite_master table. The problem is that the information on the attributes of each table is returned as a string : eg: Type : table Name : names Table Name : names Root Page : 2 CREATE TABLE names (id INTEGER PRIMARY KEY, name) I plan to use the SQL::Parser library in order to derive all attribute information from this string. Is there a better way to go about it ? My aim is to find something equivalent to "DESC tablename" (used in sqlplus) There is core DBI support for this (which DBD::SQLite talks to). See the table_info section of the DBI man page. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Should Unary + Cast to a Number?
On 17 Mar 2005, at 15:13, David Wheeler wrote:
Probably off-topic for a SQLite list :-)
I'm not sure Perl will cast a non-numeric string
("2005-03-22T00:00:00") to a number. What number are you
looking for?
Actually the code that was cast was "substr(a, 6, 2)", which was
evaluating to "03", and I wanted it to be just 3, because when I bind
"03" in DBD::SQLite, it changes it to 3.
You can force the binding type in DBD::SQLite - see the DBI docs (grep
for ":sql_types").
Matt.
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: [sqlite] Sqlite3 BLOB support
On 29 Sep 2004, at 11:23, Serge Semashko wrote: Hello all, I'm sorry for a probably lame question, I'm new to sqlite and database programming. Is it possible to store very large files in sqlite3 database? Are there any limitations? http://www.sqlite.org/faq.html#q10 Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Lock files....
On 24 Sep 2004, at 17:43, Ara.T.Howard wrote: On Fri, 24 Sep 2004, Matt Sergeant wrote: On 24 Sep 2004, at 14:51, Ara.T.Howard wrote: What are people's views on this? i think it's sufficiently common to merit discussion on best practices at least. More than that, I'm thinking there might be a call for an os_nfs.c that uses this NFS clean locking mechanism. which nfs clean locking mechanism? AFAIK there is not one that works across the platforms sqlite supports. The link() one you use. Some of us don't care about cross platform if we can hack in something guaranteed to work on NFS. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] New DBD::SQLite*s
On Fri, 10 Sep 2004, David Morel wrote: > Le ven 10/09/2004 à 17:51, Matt Sergeant a écrit : > > Uploaded to CPAN are DBD::SQLite 1.05 and DBD::SQLite2 0.33 > > > > Changes for DBD::SQLite2: > > > >0.33 > > - Set HAVE_USLEEP appropriately. This massively improves > >concurrent access to your SQLite DB. > > Grand. Could you solve the ATTACH problem as well? Have you filed a bug report? I don't see one. http://rt.cpan.org/ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[sqlite] Re: my own fixes for symbol conflict - encode.c
On Sun, 12 Sep 2004, Darren Duncan wrote: > Following the application of Matt Sergeant's diffs, I still had some > similar problems. But this time, seeing what kinds of things he > changed, I tracked down and fixed the problems myself. > > Below this letter is the diff of my changes, which when used in > addition to Matt's, allowed me to use SQLite2 and SQLite3 together > (for that test anyway) under Mac OS X 10.2.8. > > This change is in the SQLite core, the file "encode.c" to be > specific, so someone with commit privileges on sqlite.org will have > to apply it. > > In summary, I renamed all occurances of > sqlite_[encode|decode]_binary() to sqlite3_[encode|decode]_binary() > in "encode.c". I don't think encode.c is part of sqlite3 - it certainly isn't relevant now sqlite has proper blob support. I suspect it got left in DBD::SQLite as a remnant of the previous version. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sun, 12 Sep 2004, Matt Sergeant wrote:
> On Sat, 11 Sep 2004, Darren Duncan wrote:
>
> > At 12:49 AM +0100 9/12/04, Matt Sergeant wrote:
> > >This is just because Mac OSX is fussy - Linux won't complain and will let
> > >the latterly loaded symbol supercede. But it's a valid bug in
> > >DBD::SQLite2, so I'll fix it in the next release (should be simple).
> > >Matt.
> >
> > Now, unless you have a Mac OS X box of your own to test against,
> > please send me a copy of the changed source files (the whole files,
> > not diffs) asap, and I'll test your current distro with those
> > changes. This way, if something else comes up, I can have tested
> > that it works good prior to you uploading it to CPAN. I'll be
> > waiting for them. -- Darren Duncan
>
> All DBD::SQLite dev is done on OS X (Panther currently). So it should be
> easy.
Ah, ok so Panther fixed the annoying strictness of Jaguar. However I think
the following patch should cover all bases:
Index: SQLite.xs
===
RCS file: /home/cvs/DBD-SQLite/SQLite.xs,v
retrieving revision 1.6
diff -u -r1.6 SQLite.xs
--- SQLite.xs 2004/07/21 20:50:42 1.6
+++ SQLite.xs 2004/09/12 10:02:30
@@ -37,7 +37,7 @@
SV *func
CODE:
{
-sqlite_db_create_function( dbh, name, argc, func );
+sqlite3_db_create_function( dbh, name, argc, func );
}
void
@@ -48,7 +48,7 @@
SV *aggr
CODE:
{
-sqlite_db_create_aggregate( dbh, name, argc, aggr );
+sqlite3_db_create_aggregate( dbh, name, argc, aggr );
}
int
@@ -56,7 +56,7 @@
SV *dbh
int timeout
CODE:
-RETVAL = sqlite_busy_timeout( dbh, timeout );
+RETVAL = dbd_set_sqlite3_busy_timeout( dbh, timeout );
OUTPUT:
RETVAL
Index: dbdimp.c
===
RCS file: /home/cvs/DBD-SQLite/dbdimp.c,v
retrieving revision 1.50
diff -u -r1.50 dbdimp.c
--- dbdimp.c2004/08/29 10:11:57 1.50
+++ dbdimp.c2004/09/12 10:02:30
@@ -128,7 +128,7 @@
}
int
-sqlite_busy_timeout ( SV *dbh, int timeout )
+dbd_set_sqlite3_busy_timeout ( SV *dbh, int timeout )
{
D_imp_dbh(dbh);
if (timeout) {
@@ -761,7 +761,7 @@
}
void
-sqlite_db_create_function( SV *dbh, const char *name, int argc, SV *func
)
+sqlite3_db_create_function( SV *dbh, const char *name, int argc, SV *func
)
{
D_imp_dbh(dbh);
int rv;
@@ -975,7 +975,7 @@
}
void
-sqlite_db_create_aggregate( SV *dbh, const char *name, int argc, SV
*aggr_pkg )
+sqlite3_db_create_aggregate( SV *dbh, const char *name, int argc, SV
*aggr_pkg )
{
D_imp_dbh(dbh);
int rv;
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sat, 11 Sep 2004, Darren Duncan wrote: > At 12:49 AM +0100 9/12/04, Matt Sergeant wrote: > >This is just because Mac OSX is fussy - Linux won't complain and will let > >the latterly loaded symbol supercede. But it's a valid bug in > >DBD::SQLite2, so I'll fix it in the next release (should be simple). > >Matt. > > Now, unless you have a Mac OS X box of your own to test against, > please send me a copy of the changed source files (the whole files, > not diffs) asap, and I'll test your current distro with those > changes. This way, if something else comes up, I can have tested > that it works good prior to you uploading it to CPAN. I'll be > waiting for them. -- Darren Duncan All DBD::SQLite dev is done on OS X (Panther currently). So it should be easy. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sat, 11 Sep 2004, Darren Duncan wrote: > And the results: > > [S0106000393c33758:Documents/Perl Distributions/devworld] > darrenduncan% ../perl58 dbd_load_test.pl > dyld: ../perl58 multiple definitions of symbol _sqlite_busy_timeout > /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite/SQLite.bundle > > definition of _sqlite_busy_timeout > /Volumes/Programming/Perl/lib/perl5/site_perl/5.8.5/darwin/auto/DBD/SQLite2/SQLite2.bundle > > definition of _sqlite_busy_timeout > Trace/BPT trap > > The error messages are the same as before, which is the important > part. Perl dies hard; this isn't a trappable error. > > Does the above code sample work on your machine? This is just because Mac OSX is fussy - Linux won't complain and will let the latterly loaded symbol supercede. But it's a valid bug in DBD::SQLite2, so I'll fix it in the next release (should be simple). Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[sqlite] Re: symbol conflict in v3 with v2 - using DBD::SQLite/2
On Sat, 11 Sep 2004, Darren Duncan wrote: > However, this SQLite v2 and SQLite v3 can not be used simultaneously > as they have symbol conflicts. The one flagged was > _sqlite_busy_timeout, but from a quick scan of the offending files > there seem to be more conflicts. It all looks like a number of > 'sqlite' not being changed to 'sqlite3'. [snip] > Since I don't know whether the problem is in the core or in the Perl > bindings, should I file a ticket on SQLite.org for this? Looks like it's probably a "bug" in the perl bindings. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] New DBD::SQLite*s
On Fri, 10 Sep 2004, Darren Duncan wrote: > With this round, I will start using the new stuff like named host parameters. Sadly named host params are still broken in sqlite 3.0.6. When I parse this SQL: SELECT user_id, fname, lname FROM users WHERE lname like :1 UNION SELECT user_id, fname, lname FROM users WHERE fname like :1 the sqlite library still thinks I have 2 bind parameters, which breaks trying to execute that with one parameter under the DBI. I suspect this could be just a bug in sqlite3_bind_parameter_count, or the way sqlite internals count the number of parameters. Plus I have yet to implement code for named parameters to work. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[sqlite] New DBD::SQLite*s
Uploaded to CPAN are DBD::SQLite 1.05 and DBD::SQLite2 0.33 Changes for DBD::SQLite2: 0.33 - Set HAVE_USLEEP appropriately. This massively improves concurrent access to your SQLite DB. Changes for DBD::SQLite: 1.05 - Enabled HAVE_USLEEP where available which should massively improve concurrent usage of DBD::SQLite - Update to sqlite 3.0.6 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] host parameters / bind variables - further workouts
On 26 Aug 2004, at 19:15, Darren Duncan wrote:
At 2:39 PM +0100 8/26/04, Matt Sergeant wrote:
I already support sqlite3's numeric placeholders via the standard DBI
API. Switching to non-numeric placeholders will be more complex (I'll
have to use a hash instead of an array to store the placeholders) but
quite doable.
In case I was giving off the wrong idea, I don't mean to lose support
for the positional parameters, but rather to support both posit/named
concurrently.
But yes, the ability to do this would be very powerful, but hopefully
very simple to implement:
...
my $sth = $dbh->prepare(
"SELECT * FROM bar ".
"WHERE baz = :yours OR foo = :mine OR zee = :yours" );
$sth->execute( { 'yours' => 3, 'mine' => 'hello' } );
...
$sth->execute( { 'yours' => 6, 'mine' => 'goodbye' } );
...
Yes. Should be possible - I'll have to switch from an array storage to
hash storage of the parameters, but that's not a huge deal.
For Richard's benefit though, I tested the currently documented: ":N:"
style parameters and I can't compile a SQL statement with those in,
which is a bit worrying (this is with sqlite 3.0.4).
Matt.
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: [sqlite] Getting the Number of row returned by a query.
On Sat, 21 Aug 2004, WysG wrote: > Well no that's not true, I found a "sloppy way" of getting the number of > row, that is executing the same query 2 times, once with sqlite3_exec > and a callback that does oRs->intRecordCount++ and then with > sqlite3_prepare to get the vm > > Is that the only way to get the record count ? Either that, or calling the SQL first with count(). SQLite's vm doesn't know the number of rows until it's looped through all the rows. It can't by design IIRC. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
[sqlite] Re: [OT] Re: [sqlite] locking via windows nfs client
On Fri, 20 Aug 2004, Ara.T.Howard wrote: > > NFS locks can get stale if you have network problems. The server loses the > > client, the lock remains on the server, nobody can lock the file. Everyone > > using NFS eventually runs into this, but good network setup and good kernel > > choices can often mitigate it. > > ours is pretty good but i have that exact situation right now. it's happened > in a peice of code i've designed to try and break nfs locking. it forks > children which get a lock and don't release it, but simply '_exit'. also, the > parent randomly sends SIGKILL to the children after forking them. this loops > as fast as possible on many clients locking the same file. it takes a few > days, but i can create the situation you describe. i've got a stale lock now > that i can see in /proc/locks - and can see the pid of it, but cannot find > this pid on any system. do you know if there is a way to find out which host > the nfs sever thinks the lock is on? i've got a thread going on the nfs list > regarding this > but have gotten no help on the specific issue. On a netapp you can show locked inodes and it lists them by host. I have no idea about other implementations. I suspect this is very platform dependant. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] locking via windows nfs client
On 18 Aug 2004, at 23:13, Ara.T.Howard wrote: has anyone out there used sqlite from a windows machine when the db resided on an nfs filesystem mounted using the windows nfs client? if so, does it work? have you attempted concurrent access from other windows machines? other *nix machines? i'm considering an application where process from both linux and window machines may access an sqlite db located on a shared nfs fs. As far as linux -> nfs access goes it all depends on the quality of the NFS implementation, and the kernel drivers you're using. It's not easy to create a stable NFS locking system. We've had lots of problems with it. If you can, go with local disk. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re[2]: [sqlite] full text search working from CD ROM ( Steve O'Hara's solution )
On Thu, 12 Aug 2004, Pavel wrote: > MS> There are some modules on CPAN which provide generic full text search > MS> backed on any RDBMS. Try http://search.cpan.org/ > > CPAN was my first search, only was I found was DBIx::FullTextSearch > that require MySQL and DBIx::TextIndex that search in BLOB column (and > not in index). > > Or I am missing something (most likely)? Just port the code to SQLite. It won't be much work. Or use Plucene. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] OT: Reply-To Munging Considered Useful
On Fri, 23 Jul 2004, Brass Tilde wrote: > > Better: Somebody please write me a simple, secure, mail handler to > > replace qmail/ezmlm that lets each user decide for themselves whether > > they want a Reply-To back to the mailing list or unmunged headers. > > > > I'll be happy to supply volunteers with a detailed specification of > > what I am looking for in a mail system. > > Funny you should mention that. I've been looking for one of those myself, > and had half decided to write my own. Problem is, I don't know anything > about mail processing, so it's going to be a long road. > > If you don't mind though, I'd like to see those specs. Even though I can't > promise you anything, I'm interested in seeing other folks' ideas. If you > have them already put together, of course; I don't expect you to create them > for me when I can't deliver what you're looking for. http://siesta.sourceforge.net/ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] OT: mailing list nomail option?
You can do this with ezmlm, but it requires Richard to set something up on the sqlite.org server - a new subscription address ([EMAIL PROTECTED]) which just adds users to the "allow" file. I don't know how easy or hard that would be though. On 21 Jul 2004, at 10:51, Nuno Lucas wrote: Hi, I decided to switch to the gmane newsgroup way of reading this mailing list. But I don't seem to find any way of keeping subscribed and not receiving any mail. Gmane says to send a message to [EMAIL PROTECTED], but that doesn't seem to work. Is there another way, or should I just put a filter to delete all messages from the list? I remember someone talking about this, but I couldn't find the post... I also noticed I can't use gmane to send the message (I must send as regular mail to [EMAIL PROTECTED]). Anyone knows why? Regards, ~Nuno Lucas __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Improved Interpreter in latest SQLite version?
On 19 Jul 2004, at 23:56, gohaku wrote: Does sqlite v3.0.2 include such an interpreter? No. I use dbish which is from the perl DBI::Shell package (on CPAN). If you install the right modules it has scrollback, EDITOR support, etc. Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] sqlite3_changes not working for DELETE
On 15 Jul 2004, at 21:03, D. Richard Hipp wrote: Matt Sergeant wrote: In sqlite3, I can't get sqlite3_changes working for DELETE. I notice there's no tests for this. (I'm talking "DELETE FROM T WHERE ..." rather than flat out DELETE all). Can anyone else confirm this? There is at least one existing test for this (laststmtchanges-1.5). I've added a few more. I can't get it to fail. Can you supply a specific example where it isn't working? OK, I figured it out. Once again it was my naive data type binding - I had assumed a blob would be like a string but allow binary nulls. My bad. So now I have: All tests successful. Files=24, Tests=355, 6 wallclock secs ( 3.12 cusr + 0.91 csys = 4.03 CPU) Woohoo! Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] sqlite3_changes not working for DELETE
On 15 Jul 2004, Hans-Juergen Taenzer wrote: > Matt Sergeant ([EMAIL PROTECTED]) wrote: > > > This is now the only thing holding back DBD::SQLite's port to > > sqlite3. I've got everything else working and it's all looking > > great. inserts are about the same speed as sqlite2, but selects > > have sped up about 30%. > > That's not my experience. Inserts und updates are much faster, but > searching with VMs (compile,bind,step) are about 20% slower than with > SQLite 2.8. Thats true on Linux and Win32. And because my little > application (Bayesian Spamfilter) ist mostly searching I've to stay with > SQLite 2.8 In my defense, my benchmark is very naive :-) Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] Storing large files
On 15 Jul 2004, at 15:53, D. Richard Hipp wrote: In SQLite version 3.0, there is no theoretical limit on the size of BLOBs. (The limit is really about 4.6e+18 bytes, but file size limits will come into play first so you will never get to that size.) However, the same MAX_BYTES_PER_ROW constraint is still in place. So with a default build, the maximum BLOB size is still about 1MB. You can, I suppose, increase MAX_BYTES_PER_ROW to whatever value you want and recompile. But, if you make MAX_BYTES_PER_ROW really big, I think you will find that performance gets very bad for very large rows. OK, but what is performance like for small rows if you increase MAX_BYTES_PER_ROW? Matt. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: [sqlite] OK to drop support for legacy file formats?
On 9 Feb 2004, at 14:53, D. Richard Hipp wrote: Brass Tilde wrote: My understanding is that SQLite has had this auto-update feature since version 2.6.0. If I understand correctly, you should only have a problem if you are *now* using a version prior to that, and go from that version directly to 2.8.12 or later. If you've kept your version of the db engine current, or at least have upgraded to 2.6.0 or later, then all of your databases should now have their indices updated by now. Have I misinterpreted something? Your interpretation is correct. Dropping the auto-update feature would only impact people who jump directly from version 2.5.6 or earlier to version 2.8.13 or later, ignoring 19 months of changes and improvements in between. Yes, but I assume you're also suggesting that next time you change the DB format you won't add in auto-update. That might make things painful. Is my assumption wrong? Matt. This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] OK to drop support for legacy file formats?
On 6 Feb 2004, at 14:05, D. Richard Hipp wrote: If you use a modern version of SQLite (version 2.6.0 through 2.8.11) to open an older database file (version 2.1.0 through 2.5.6) the library will automatically rebuild all the indices in the database in order to correct a design flaw in the older database files. I am proposing to drop support for this auto-update feature. Beginning with 2.8.12, if you attempt to open a database file built using version 2.5.6 or earlier, the open attempt will fail (with an appropriate error message). You will have to update the database file manually. Would this proposed change cause anyone unreasonable hardship? I can see both sides of this. On the one hand I'm a *big* supporter of keeping SQLite small, but on the other hand I have a project with currently over 50,000 sqlite databases on a large (terabyte) filesystem. Upgrading each one with a utility (and the associated downtime) would be a bit of a nightmare. Upgrading them on a per-access basis like the current implementation would do is a bit more agreeable to me. Tough choice. Matt. This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Error on commit
On 29 Jan 2004, at 18:23, Williams, Ken wrote:
create_new_sqlite_database();
$dbh->do("BEGIN");
add_lots_of_rows_to_lots_of_tables();
$dbh->do("COMMIT");
Change to:
create_new_sqlite_database();
$dbh->{AutoCommit} = 0;
add_lots_of_rows_to_lots_of_tables();
$dbh->commit;
# Optionally...
$dbh->{AutoCommit} = 1;
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] [Repost] Implementing Full Text Search
On 20 Jan 2004, at 7:25, George Ionescu wrote: The question is this: since most of RDBMS implement full text search, shouldn't this be a feature sqlite could support ? SQLite is "lite" on purpose. Most RDBMS also support data types, as a counter example. Matt. This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] DBD::SQLite SQL logic error on ATTACH
On 31 Dec 2003, at 12:33, David Morel wrote:
$dbh = DBI->connect("DBI:SQLite:/var/db/INSPIRON.primaire.sql");
$dbh->do( "ATTACH '/var/db/INSPIRON.secondaire.sql' AS secondaire ;" );
of course, the very same command succeed when typed in sqlite
Is this a bug or am I doing something wrong ?
Possibly (probably?) a bug.
Matt.
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Spiders vandalizing the wiki
On 25 Nov 2003, at 12:48, D. Richard Hipp wrote: In the past couple of days, I've been having problems with spiders vandalizing the Wiki at http://www.sqlite.org/cvstrac/wiki. The damage (so far) has been relatively minor and easy to fix. But I've been monitoring these spiders for a while and notice that they are becoming increasingly aggressive. If you have any suggestions on what to do about them, I'd like to hear from you. My suggestion is to use a trap. A robots.txt guarded area that users won't click on but occurs early at the top of the main index page. If any IP visits that page install a firewall or httpd.conf block of some description. Beyond that, ensuring that to change a page requires a secure hash auth system (i.e. can't submit earlier than 5 seconds after downloading the edit page, and can't submit later than N minutes) works very well. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Confusion regarding unsubscribe
OK, first off the simple fact: Unsubscribe is working perfectly. Now the confusion is brought about by the fact that there are now *two* lists. There's the old Yahoo Groups list. This is the one that gets spam (which is the reason we moved to a new list). Then there's the new list that is [EMAIL PROTECTED] When we created this list all the subscriptions were copied over (not moved, copied). This should have been made clearer so I apologize for that. If you want to unsubscribe fully you need to unsubscribe from both lists. I don't know how you unsubscribe from yahoo groups. Please don't ask me. To unsubscribe from the new list follow the instructions at the bottom of this post. Please don't email me privately asking for help until you have done both and waited a reasonable length of time for confirmations to go through. If nothing is working for you I will try and help, but please make sure you've covered all bases first. Thanks. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Testing the new SQLite mailing list
On 17 Oct 2003, at 15:41, Eric Schuyler wrote: I am having the same problem unsubscribing. My original subscription and the unsubscribe request came from *exactly* the same e-mail address ([EMAIL PROTECTED]). It looks like this feature isn't working correctly. Your unsubscribe request was received at the server. I have tested the unsubscribe feature and I know it is working - unfortunately the qmail logs aren't detailed enough to tell me that a confirmation was sent back to you (outbound mails it only says the recipient, not the sender). Are you sure it didn't either get rejected at your end, or you're just not waiting long enough? If you want manually removed I can do that. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
