"Gilles Ganault" <gilles.gana...@free.fr> schrieb im Newsbeitrag news:0sap559atknanmiv8g83pdj6f83e8ve...@4ax.com... > On Sat, 11 Jul 2009 09:38:27 -0700, Jim Dodgen > <j...@dodgen.us> wrote: > >I would just use: > > > >SELECT id AS Identification FROM foobar > > Thanks. This is what I already use for displaying the results, but > then I'm stuck when I need to perform INSERT/UPDATES because I need to > get the actual columns names :-/ > > It'd be cool if each column in a table could have an internal name and > an external name. > > Is there a better way than either using the very first row in each > table or keeping a table for this purpose?
There are SQLite-APIs for that purpose, which hand out the original columnname to you: sqlite3_column_origin_name or the original tablename (useful in Joins): sqlite3_column_table_name or the original database-name: sqlite3_column_database_name All based on the current statement-handle of your Select. You need a library-compile, with enabled: SQLITE_ENABLE_COLUMN_METADATA If that switch is "on", you can also make use of: sqlite3_table_column_metadata in addition, to retrieve even more infos about the current column in question (if it is a "NotNull"-column, or a Primary-Key-Column, etc.) You can do all that (looping over the appropriate column- count of your select) before entering the sqlite-step-loop - and return these additional "header-infos" in appropriate structures (together with your result-data-set). The overhead, to retrieve all these additional infos is not all that large - barely noticeable - the Recordset-Objects of my wrapper always work in that mode (delivering all of the data, but also these additional Field-infos) - and it does not affect the overall-performance - much more time is spent in the step-loop, which retrieves the real recorddata-content. Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
