Am 03.07.2013 14:50, schrieb Keith Medcalf:
Given all that, I will NEVER use the pure sql (if I can use any
other solution).
given that the "ordinal in the result set" is a fallacious
concept being created for the convenience of an application
> program which cannot deal with sets properly ...
Oh, so convenience is now bad suddenly?
Why do you think, libraries like SQLite exist at all?
They're there to offer *convenience* - to save other
developers some time (or headaches)... thanks to the
SQLite-team BTW at this occasion - you've developed a
really convenient "time-saver" here over the years for
a lot "of us"...
But given your logic, should the usage of e.g. literals in SQL-
Field-expressions be forbidden now too? ... because:
"this is stuff, which should be handled at the application-
level, otherwise the developer is to blame, for abusing
the concept of relational databases..."
What kind of theorizing is that here... there's a whole lot
of stuff in DBEngines, libraries (and in SQL as well), which
is just there for convenience.
Having a Counter-Number conveniently available (without creating
a clumsy performance-hog as James K. Lowden was suggesting) is
a reasonable request from a *practical* point of view and pretty
cheap to implement.
So, I'm voting +1 for that...
Because there's a lot of things one can use that for - especially
when you consider the concept of disconnected Recordsets, which
can be passed around in an application, or across thread- or
machine-boundaries - generic container-classes, which can be
bound to grids - or used as the datasource for parts in a Report
... in any of those cases such a "directly contained info" can
be useful, when it's already "there in the returned set-object
as a calculated column-value".
It would allow to write more "generic code" at the app-level -
when for e.g. the visualizing of Line-Numbers (or to remember
or visualize an initial-Sort-Order) in a Grid for example, one
could just "hang the Recordset-Datasource in 'as is'" - without
having to resort to "manually managing the filling of a spare-
column" within that Grid in question, because the information
was not contained as a Field in the Recordset-Container-Class.
If SQL allows to create (from a Double-typed-Field as the
Input-source) a convenient, directly displayable visual output,
handing out "calculated Percent-Strings, nicely formatted to
two decimal-places after the dot" over an SQL-expression... -
well, then I don't understand what all the fuss is about here,
when there's only the simple request for a *little* bit
"more of the same" in this regard...
Olaf
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
