[Gambas-user] Issue 612 in gambas: BUG Cannot browse more of 128 records on tables "No current connection"
Benoît Minisini
gambas at ...1...
Sat Mar 28 19:28:27 CET 2015
Le 28/03/2015 19:09, Benoît Minisini a écrit :
> Le 28/03/2015 18:58, Lewis Balentine a écrit :
>> I have over three decades of dealing with SQL and I can still not
>> understand how this myth got propagated.
>>
>> There is NO valid SQL reason why a table should be required to have a
>> unique primary key or any predefined key for that matter. One can always
>> use the row number (record number) if such a key is required for one's
>> application.
>>
>
> The row number does not exist in all database systems (more precisely,
> it is not accessible to the outside), so I can't rely on that feature to
> identify a row uniquely.
>
> Maybe the row id is not standard SQL, if "standard SQL" has any meaning.
>
> Consequently, I need a unique index, usually the primary key.
>
> If you can tell me how to get the row id of a row in MySQL, PostgreSQL
> and SQLite (mabe it has changed since the last time I looked at it), I
> will reconsider my position. :-)
>
> Regards,
>
More explanations...
I said "row number", I wanted to say "row id".
MySQL has no row id concept apparently. PostgreSQL has something like
that, but apparently not useful. SQLite has.
The answer is always the same: you need a "row id"? Add a unique primary
key based on a serial/auto-increment integer field.
Now as for as "row number".
I could use the "LIMIT / OFFSET" syntax to return the different part of
a request, instead of using "LIMIT" + a criteria on the primary key.
Alas PostgreSQL (for example), tells us that two identical "LIMIT /
OFFSET" on the same request does not necessarily return the same
records, unless you specify an predictible "ORDER BY" clause.
Moreover "OFFSET" is not optimized on PostgreSQL.
So I don't see a better solution than the current one.
--
Benoît Minisini
More information about the User
mailing list