Hello,
A few days ago I posted a question and I haven't seen any comments so
far. I'm really curious about ROWID's volatility. How can I make sure
that ROWIDs do not get re-initialized? I'm posting the message once
again hoping that someone will explain how I should properly use
ROWIDs.
Thanks again. Best regards,
-- Tito
**
Would this explanation about ROWID make sense?:
Referencing ROWID: If you make references to ROWID but then export
your database (using, for example, the ".dump" command of the sqlite
shell) and reimport it, all of your ROWIDs will change and your
references won't
be right any more. If you use an INTEGER PRIMARY KEY, the ".dump"
command will preserve the values and your references will not be
broken by the export.
*** IMPORTANT ***: Please note that ROWID columns are always created
by SQLite, even if you don't specify it when creating the table via
CREATE TABLE. If this is the case and you do something like this:
SELECT * FROM
the data returned will not include the ROWID columns, since it really
isn't part of the schema. It's always safer to include the ROWID
column in the CREATE TABLE statement, since you'll always have a
chance to display ROWID's contents.
I have copied part of the text from an old posting written by Dr. Hipp.
My questions are:
- if I declare ROWID as INTEGER PRIMARY KEY in the CREATE TABLE
statement, would that be enough to guarantee that the ROWID is safely
dumped and reimported?
- Or is ROWID *always* rearranged when reimporting?
- If this is the case I guess I would have to create my own unique
column (i.e. MyUniqueUID and type INTEGER PRIMARY KEY, right?)
- The part that confuses me about Dr. Hipp's statement is this: 'If you
use an INTEGER PRIMARY KEY, the ".dump" command will preserve the
values and your references will not be broken by the export.': this is
the reason I posted my first question above...
Any comments?
Thanks!
-- Tito
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
