[sqlite] Fwd: SAVEPOINT name

On Thu, May 21, 2015 at 7:15 PM, Simon Slavin wrote: > > > Also, savepoint names can't be used as parameters when binding. Does that mean that I can't prepare this: "SAVEPOINT :name"? What would be the recommended method of preventing SQL injection for this? -- ?u?op-?p?sdn s? ?o??uo? ?no?

[sqlite] SAVEPOINT name

On 21 May 2015, at 8:51pm, Baruch Burstein wrote: > Does that mean that I can't prepare this: "SAVEPOINT :name"? What would be > the recommended method of preventing SQL injection for this? Is there really a need to use ad-hoc savepoint names ? You can keep reusing the same name during

[sqlite] AUTOINC vs. UUIDs

On 2015-05-21 9:14 PM, Stephen Chrzanowski wrote: > {{I just got a bounced message.. Reposting}} Both of your attempts got through. You got a bounce because you sent it to an invalid list address in addition to a valid one; one bounced the other didn't. > I've been watching this thread from

[sqlite] AUTOINC vs. UUIDs

On Wed, May 20, 2015 at 11:52:08PM +, Peter Aronson wrote: > Now you're just getting silly. ?What if the application sets all rowids, > everywhere to 1? ?The fact is, the chance of collision on a UUID is pretty > astronomically low as long as a decent source of entropy is used >

[sqlite] BestIndex problem

Greetings, We are having an issue with BestIndex in our Virtual Table implementation. Allow us to illustrate the problem with a simple example. We create a virtual table named 'vt' that conceptually has 3 columns "value1, value2, value3" and then we want to execute the following queries: 1)

[sqlite] Fwd: SAVEPOINT name

Hi, What are the restrictions (if any) on a sve point name? Alphanumeric? Same as a string (enclosed in ' ' if necessary)? Something else? Thank you, Baruch -- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ??

[sqlite] in Linux system, 2 threads can access 2 separate databases (created by sqlite3) through sqlite3?

dear, thanks for your reading. I have 2 different databases , and I create 2 threads to access such 2 databases with sqlite3 sql statement? can it be done successfully like this using sqlite3 lib? is it need to control access of such 2 thread for competition ? for example ,

[sqlite] Fwd: SAVEPOINT name

On 21 May 2015, at 3:56pm, Baruch Burstein wrote: > What are the restrictions (if any) on a sve point name? Alphanumeric? Same > as a string (enclosed in ' ' if necessary)? Something else? No official documentation, as far as I know. The nearest is this:

[sqlite] AUTOINC vs. UUIDs

I agree with Keith and disagree with Simon. Regarding the current state for sequence generators that are specific to user databases, storing that state inside the same databases where they are used is exactly the right place. Everything necessary to understand a database should be stored in

[sqlite] ALTER TABLE ADD COLUMN

On Thu, 21 May 2015 12:45:41 +0200, "Christoph P.U. Kukulies" wrote: >Am 21.05.2015 um 10:00 schrieb Kees Nuyt: >> On Thu, 21 May 2015 09:40:53 +0200, "Christoph P.U. Kukulies" >> wrote: >> >>> Am 21.05.2015 um 09:25 schrieb Hick Gunter: alter table [database] add column [real_length]

[sqlite] AUTOINC vs. UUIDs

On 2015-05-21 12:16 PM, James K. Lowden wrote: > On Wed, 20 May 2015 19:05:29 +0100 > Simon Slavin wrote: > >> Posting this not because I agree with it but because the subject has >> come up here a couple of times. >> >>

[sqlite] BestIndex problem

None of the queries named requires more than 1 parameter to xFilter. Why should they? xBestIndex will be called once with no usable constraints and once with (value1, "="). The difference is that xFilter will be called once for each constraint value, i.e. once for query 1 and twice for

[sqlite] Fwd: SAVEPOINT name

On 5/21/2015 3:51 PM, Baruch Burstein wrote: > Does that mean that I can't prepare this: "SAVEPOINT :name"? Yes. > What would be the recommended method of preventing SQL injection for this? Do you plan to run SAVEPOINT "user-provided-string"? What for, if you don't mind me asking? -- Igor

[sqlite] AUTOINC vs. UUIDs

On Thu, 21 May 2015 13:44:15 +0200 Mark Straver wrote: > > Oh and the other feature! of UUIDs is merging databases... if I > > have a database deployed to 15 customers, each with their own ORGID > > I can easily throw them in the same database without worrying about > > fixing up primary keys

[sqlite] AUTOINC vs. UUIDs

On Wed, 20 May 2015 19:05:29 +0100 Simon Slavin wrote: > Posting this not because I agree with it but because the subject has > come up here a couple of times. > > > > > "Today, I?ll talk about

[sqlite] Copy data between to databases unsing windows embedded compact 7, .net 3.5

Hi, I am developing an application for Windows Compact Embedded 7 using .net 3.5 and sqlite. We have two databases, db1, db2. A table shall b e copied from db1 to db2 using .net and c#. INSERT INTO db1.table SELECT * FROM db2.table How can I execute this command using ado.net 3.5 (Ce.net

[sqlite] AUTOINC vs. UUIDs

On 5/21/2015 1:37 PM, Valentin Davydov wrote: > Moreover, there are widespread examples of colliding UUIDs, say > EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. This particular issue ( http://lists.gnu.org/archive/html/bug-parted/2011-06/msg00026.html ) didn't happen because two independent UUID

[sqlite] AUTOINC vs. UUIDs

On 21/05/2015 09:33, J Decker wrote: > chance of collision is slim... it's a truly large amount of bits... > There's libuuid for linux, and builtin functions for windows to create them. The chance of collision is only slim if you (as some people have already indicated) have a proper entropy

[sqlite] Copy data between to databases unsing windows embedded compact 7, .net 3.5

ATTACH is the command you are looking for -Urspr?ngliche Nachricht- Von: afriendandmore [mailto:afriendandmore at ymail.com] Gesendet: Donnerstag, 21. Mai 2015 15:15 An: sqlite-users at mailinglists.sqlite.org Betreff: [sqlite] Copy data between to databases unsing windows embedded

[sqlite] AUTOINC vs. UUIDs

> > As a result, I don't think it's wise to use them, objectively speaking. It has > very little to do with having used them in the past myself or not (OT: that is > actually a psychological trap employed by many shady business models ;) ). > I do hope that if you use them, you never run into

[sqlite] AUTOINC vs. UUIDs

On Thu, May 21, 2015 at 11:37 AM, Valentin Davydov wrote: > On Wed, May 20, 2015 at 11:52:08PM +, Peter Aronson wrote: > > Now you're just getting silly. What if the application sets all rowids, > > everywhere to 1? The fact is, the chance of collision on a UUID is > pretty > >

[sqlite] ALTER TABLE ADD COLUMN

Am 21.05.2015 um 10:00 schrieb Kees Nuyt: > On Thu, 21 May 2015 09:40:53 +0200, "Christoph P.U. Kukulies" > wrote: > >> Am 21.05.2015 um 09:25 schrieb Hick Gunter: >>> alter table [database] add column [real_length] numeric; >> Thanks, that did it right. Almost. Still I'm wondering why >> the

[sqlite] ALTER TABLE ADD COLUMN

On 21 May 2015, at 7:51am, Christoph P.U. Kukulies wrote: > Now I wonder why I don't read > CREATE TABLE [database] ( > [database_name] TEXT NULL, > [table_name] TEXT NULL, > [data_type] TEXT NULL, > [data_size] INTEGER NULL, > [column_name] TEXT NULL, > [vendor] TEXT DEFAULT 'SQLBASE'

[sqlite] ALTER TABLE ADD COLUMN

Am 21.05.2015 um 09:08 schrieb Jean-Christophe Deschamps: > At 08:51 21/05/2015, you wrote: > >> I used sqlite3.exe by invoking it on the command line with the name >> of a database. >> Next I typed >> >> alter table database add column real_length numeric; >> >> Next I typed .fullschema >> and

[sqlite] ALTER TABLE ADD COLUMN

Am 21.05.2015 um 09:25 schrieb Hick Gunter: > alter table [database] add column [real_length] numeric; Thanks, that did it right. Almost. Still I'm wondering why the output is not as "smooth" as the .fullschema listing before the ALTER ADD COLUMN: (comma at line start, lower case 'numeric')

[sqlite] ALTER TABLE ADD COLUMN

At 08:51 21/05/2015, you wrote: >I used sqlite3.exe by invoking it on the command line with the name of >a database. >Next I typed > > alter table database add column real_length numeric; > >Next I typed .fullschema >and I'm getting: > >sqlite> .fullschema >CREATE TABLE [database] (

[sqlite] ALTER TABLE ADD COLUMN

I used sqlite3.exe by invoking it on the command line with the name of a database. Next I typed alter table database add column real_length numeric; Next I typed .fullschema and I'm getting: sqlite> .fullschema CREATE TABLE [database] ( [database_name] TEXT NULL, [table_name] TEXT NULL,

[sqlite] ALTER TABLE ADD COLUMN

Try alter table [database] add column [real_length] numeric; -Urspr?ngliche Nachricht- Von: Christoph P.U. Kukulies [mailto:kuku at kukulies.org] Gesendet: Donnerstag, 21. Mai 2015 08:51 An: General Discussion of SQLite Database Betreff: [sqlite] ALTER TABLE ADD COLUMN I used

[sqlite] AUTOINC vs. UUIDs

At 01:33 21/05/2015, you wrote: >HUIDs have the birthday problem. How many people do you need to have >in a group before two of them will have the same birthday? HUIDs can >only be called LUID's (Locally Unique Identifiers) if you go to the >trouble of ensuring uniqueness *before* using one.

[sqlite] AUTOINC vs. UUIDs

Sorry to be argumentative. I'll drop it. On Thu, May 21, 2015 at 4:44 AM, Mark Straver < sqlite-users-list at palemoon.org> wrote: > On 21/05/2015 09:33, J Decker wrote: > > chance of collision is slim... it's a truly large amount of bits... > > There's libuuid for linux, and builtin functions

[sqlite] AUTOINC vs. UUIDs

On 2015-05-21 01:52 AM, Peter Aronson wrote: > Now you're just getting silly. What if the application sets all rowids, > everywhere to 1? The fact is, the chance of collision on a UUID is pretty > astronomically low as long as a decent source of entropy is used (see >

[sqlite] AUTOINC vs. UUIDs

On 20 May 2015, at 11:18pm, Scott Doctor wrote: > I can see the issue. For instance, an invoice ID related to inventory, where > the invoice ID is the PK number. Two salesmen on their iPads take an order > where their local database assigns the same PK number. When merged you have > two

[sqlite] AUTOINC vs. UUIDs

On 5/20/15, R.Smith wrote: > > ANY solution that > relies on something not guaranteed is a bad solution. Here is a disturbing truth: There are no guarantees. Those transistors that make up your CPU - they turn on and off when current is applied to their gate *with a certain probability*. The

[sqlite] AUTOINC vs. UUIDs

"Just to chime in here: First off, how are you going to generate them? How will you avoid collisions? Why should it be necessary to using that much storage space for a primary key and what's the reason for not using blazingly-fast integers?..." chance of collision is slim... it's a truly large

[sqlite] AUTOINC vs. UUIDs

Never mind about the 122 vs 124 bit thing. ?I could have swore I read that... On Wednesday, May 20, 2015 4:52 PM, Peter Aronson wrote: Now you're just getting silly. ?What if the application sets all rowids, everywhere to 1? ?The fact is, the chance of collision on a UUID is pretty

[sqlite] AUTOINC vs. UUIDs

Now you're just getting silly. ?What if the application sets all rowids, everywhere to 1? ?The fact is, the chance of collision on a UUID is pretty astronomically low as long as a decent source of entropy is used

[sqlite] AUTOINC vs. UUIDs

On May 20, 2015 10:23 PM, "Keith Medcalf" wrote: > > > Fossil does not use UUID's. No. But it uses hashes which can collide. Same principle. They are convenient in the distributed environment. Version 5 UUID algorithm is based on sha1 (truncated) and involves the sorts of deterministic data

[sqlite] AUTOINC vs. UUIDs

At 22:50 20/05/2015, you wrote: >Just to chime in here: I think using UUIDs for primary keys is an >absolutely >terrible idea, instead. First off, how are you going to generate them? How >will you avoid collisions? Why should it be necessary to using that much >storage space for a primary key