Hi Bob,
I don't think that's true. I think you can have it not autoincrement and
supply the primary key value yourself when you insert a row. In fact, you
have to do that if the primary key is one of the text data types since
autoincrement doesn't make any sense in that context.
Pete
On Mon,
Oh right duh that makes sense. I have no idea where I got that.
Bob
On Jan 17, 2012, at 11:47 AM, Pete wrote:
Hi Bob,
I don't think that's true. I think you can have it not autoincrement and
supply the primary key value yourself when you insert a row. In fact, you
have to do that if the
INT(64) is a 64-bits integer, so 8 instead of 64 bytes :-)
Still, that limit should keep you safe for some time to come...
Jan Schenkel.
=
Quartam Reports PDF Library for LiveCode
www.quartam.com
=
As we grow older, we grow both wiser and more foolish at the same time. (La
Hi Bob,
Int(64) refers to the external display of a column, not its internal
storage space. As you mentioned INT takes 4 bytes of storage but its
external display format can be up 10 chars.
I guess if you're really concerned about it, you could use BIGINT but there
is no theoretical software
On Jan 16, 2012, at 12:56 PM, Pete wrote:
In SQLite, if you define an INTEGER PRIMARY KEY column with AUTOINCREMENT
keyword, primary key values are always allocated as the next highest value
for the table, but if you omit the AUTOINCREMENT, then values freed up by
deleted rows may get
I remember in Trevor's original DB abstraction library (before SQL Yoga) he
used a manual indexing method, instead using a special table of indexes for
each table that is used. That allowed the changing the actual value of the
keys if needed. Automatic indexing is a feature that is not mandatory,
