> > Myself, I'm not a big fan of high-level abstraction from the sql
> > being performed, so I wouldn't use the originally posted idea of
> > editing a recordset.
>
> I don't tend to use it either. But some people like to do things that
> way and I'd like to make it as easy as possible for t
On May 18, 2005, at 10:40 AM, John LeSueur wrote:
Myself, I'm not a big fan of high-level abstraction from the sql
being performed, so I wouldn't use the originally posted idea of
editing a recordset.
I don't tend to use it either. But some people like to do things that
way and I'd like to ma
Will Leshner wrote:
On May 18, 2005, at 8:02 AM, Jay Sprenkle wrote:
When I wrote applications that allowed the user to enter queries
I added the unique key row to their query. I presented them with the
data they requested and either did not show the record id, or made
it read only. This allowed me
On May 18, 2005, at 8:26 AM, Jay Sprenkle wrote:
I didnt let users enter SQL. I provided a form with fields that
correspond
to the columns in the table. They could enter a search string into
the form
in the name field if they wanted to search by name, in the city
field if
they wanted a specif
> That is what I'm thinking of doing as well. What concerns me is all
> of the SQL queries that would fail if I blindly add 'rowid' as a
> column to every query. So it seems I need to be smart about what
> queries to add it to, and I'm a little worried I'm going to miss
> cases. In fact, I'm not ex
On May 18, 2005, at 8:02 AM, Jay Sprenkle wrote:
When I wrote applications that allowed the user to enter queries
I added the unique key row to their query. I presented them with the
data they requested and either did not show the record id, or made
it read only. This allowed me to correctly identi
> > By ensuring that each record receives a unique identifier and
> > including that in all queries, the main issue is resolved.
>
> Right, but the problem is that the user didn't use the unique
> identifier in the query and now I'm faced with the prospect of trying
> to muck with the user's query
I believe you are wrong. The rowid is the primary key in the SQLite
B-tree representation. It is always unique and allows you not to use
your own primary key. But if you have a column of type INTEGER PRIMARY
KEY, the values in this column become rowid. Otherwise a new
autoincremented column is
On May 17, 2005, at 8:11 PM, Ken & Deb Allen wrote:
By ensuring that each record receives a unique identifier and
including that in all queries, the main issue is resolved.
Right, but the problem is that the user didn't use the unique
identifier in the query and now I'm faced with the prospect
All database tables should be defined with a unique primary key.
Ideally this should consist of one or more integer columns; tect
columns can be used but they are universally less efficient. If the
data being stored does not contain a natural unique identifier, then
one should be added; you can
On May 17, 2005, at 2:07 PM, Jay Sprenkle wrote:
rowid won't work in a multiuser database. It's just the row number
within
the result set you retrieved. This sort of problem is the reason
why people
use a unique id field. The database automatically assigns you a number
that won't change and isn
rowid won't work in a multiuser database. It's just the row number within
the result set you retrieved. This sort of problem is the reason why people
use a unique id field. The database automatically assigns you a number
that won't change and isn't shown to the user (they can't change it either).
I develop a database wrapper for SQLite and I have an interesting
problem that I'm curious how other people solve. Basically, the users
of my wrapper have the option of editing database records indirectly
through the wrapper, rather than directly, using UPDATE. The database
wrapper is a set
13 matches
Mail list logo