Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

2017-06-07 13:57 GMT-04:00 Simon Slavin :

> The work of parsing comments in the CREATE TABLE command ?  I don’t think
> anyone else thinks this is worth working on.  Discussion in this list has
> come up with many reasons why it’s a poor way to store comments, including
>
i'm aware of them.. but its a limited support:


> * Difficulty of parsing text which may have CR, LT, tab, comma, etc..
>
use standard way, only LF no comma and TAB allowed.. POSIX always


> * Impossible to update the comments without DROPping and reCREATEing the
> table because SQLite implements only a few ALTER TABLE commands.
>
umm that's enough for limited support!


> * Documentation restricted to one language.
>
i dont understant the meaning of, why multilang comments...?


>
> Here’s a simple version of the best system I ever came up with from
> working in multi-programmer projects, where clear comments were important
> to letting one developer know what another intended.  Comments for a
> database can be stored in the following table in that database:
>
> CREATE TABLE meta_comments (
> entityType TEXT COLLATE NOCASE NOT NULL,
> theTable TEXT COLLATE NOCASE NOT NULL,
> theName TEXT COLLATE NOCASE NOT NULL,
> theComment TEXT COLLATE NOCASE NOT NULL,
> PRIMARY KEY (entityType, theTable, theName));
>
> Values for "entityType" can be ’schema’,'table','index','trigger','view',
> and anything else you want to document.
>
that its a good limited aproach! limit the comments to only 12 chars to not
overhead the db size


>
> If you need multilanguage documentation (required for some countries which
> work to protect a language) add a "language TEXT COLLATE NOCASE NOT NULL"
> field and include it in the primary key.  Ih one use of an early version of
> this we also used a field called "theVersion" to document changes in each
> entity, though I don’t know how sensible that is for most uses.  We also
> used to use a table like this to store commands, though if I was designing
> that system from scratch now I’d use a different table.
>

the mayor problem its when sqlite join two files/databases to share the
comments with the other

>
> I came up with the above structure myself, warrant that it is not
> encumbered by any intellectual property, and dedicate it to the public
> domain.  Anyone can use it for anything they want.
>
that its good...enought


>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

ipost github as example.. there a sourceforge git capabilities over large
years.. also  You can't be 100% certain that Ricahd resources is going to
be online tomorrow.. sf.net, github, gitlab and googlecode are still only
voer many years... and all of them works with openid...

for Stephen Chrzanowski  and Simon Slavin thans for their responses,
i-ll (due the stric wrokflow of old-behaviour of maillist software) will
answer in another mail to conserver the threath workflow (that its not
happened in a real issue tracker)

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-06-07 12:37 GMT-04:00 Stephen Chrzanowski <pontia...@gmail.com>:

> Why should Richard and other devs rely on something other than their own
> work and source control?  You can't be 100% certain that GitHub is going to
> be online tomorrow, which means that a scramble to push code to another
> site is going to happen.  You can't be certain that whatever comes after
> GitHub and becomes the default place to go for public code repository.
>
> What Richard has put in place is entirely under his control, his management
> style, his methodologies, and his implementation.  21st century or not,
> he's not a lemming and doesn't have to jump on the next bandwagon.
>
> As for the comment about registration, you need to register to get onto
> GitHub as well.  So outside a mail client of my choice, I now have to worry
> about a web browser and trust that the remote site is going to be
> available, what the provider is going to do with my information.
>
>
>
> On Wed, Jun 7, 2017 at 12:17 PM, PICCORO McKAY Lenz <
> mckaygerh...@gmail.com>
> wrote:
>
> > hello brian, what standars? reading deeply the sqlite site i not see the
> > @issue buton@
> >
> > only see that all contact way must be in the mail list... its a 21
> century
> > and ID urls its the standar way of integration...
> >
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> > 2017-06-07 12:12 GMT-04:00 Brian Curley <bpcur...@gmail.com>:
> >
> > > Not exactly.
> > >
> > > You're free to extend it yourself and submit it for consideration
> > though. I
> > > think that you'll just need to adopt the same standards as are in use
> > > within the usual enhancements channels.
> > >
> > > Regards.
> > >
> > > Brian P Curley
> > >
> > >
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

hello brian, what standars? reading deeply the sqlite site i not see the
@issue buton@

only see that all contact way must be in the mail list... its a 21 century
and ID urls its the standar way of integration...

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-06-07 12:12 GMT-04:00 Brian Curley <bpcur...@gmail.com>:

> Not exactly.
>
> You're free to extend it yourself and submit it for consideration though. I
> think that you'll just need to adopt the same standards as are in use
> within the usual enhancements channels.
>
> Regards.
>
> Brian P Curley
>
>
>
> On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz <
> mckaygerh...@gmail.com>
> wrote:
>
> > 2017-06-07 9:59 GMT-04:00 Richard Hipp <d...@sqlite.org>:
> >
> > > I would suggest, then, that you grab a copy of the SQLite source code,
> > > put it on github, and start your own fork.  You can then add whatever
> > > new SQL commands you want.
> > >
> > > At this point, your chances of getting us to do your work for you are
> > > very close to zero.
> > >
> > that's not was the topic.. but in any case its a response of the style:
> > "works for me, doit yourselft"
> >
> >
> > >
> > > --
> > > D. Richard Hipp
> > > d...@sqlite.org
> > >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

2017-06-07 9:59 GMT-04:00 Richard Hipp :

> I would suggest, then, that you grab a copy of the SQLite source code,
> put it on github, and start your own fork.  You can then add whatever
> new SQL commands you want.
>
> At this point, your chances of getting us to do your work for you are
> very close to zero.
>
that's not was the topic.. but in any case its a response of the style:
"works for me, doit yourselft"


>
> --
> D. Richard Hipp
> d...@sqlite.org
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

the github issue tracker are more easy to send.. register can made with any
openid service.. no a complicated email out/of/time system.. its the 21
century men

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-06-07 9:24 GMT-04:00 Stephen Chrzanowski <pontia...@gmail.com>:

> What other way would there be?  Just anonymous "Fix it, add this, do it
> now!" kind of messages?  If you don't register, then anyone can start
> spamming the hell outta the message board.
>
> On Wed, Jun 7, 2017 at 9:15 AM, PICCORO McKAY Lenz <mckaygerh...@gmail.com
> >
> wrote:
>
> > the problem its that for making some noise or request users must
> > register, send email, waith response aproval.. too complicated
> > processs.. that's the reason
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> >
> > 2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar <dkk...@gmail.com>:
> > > Patches are still welcome, I guess. I haven't seen anybody claiming
> > > that this would be done in any way.
> > >
> > > On 6 June 2017 at 15:17, PICCORO McKAY Lenz <mckaygerh...@gmail.com>
> > wrote:
> > >> how its the status of this work?
> > >>
> > >> a limited implementation will be good!
> > >>
> > >> Lenz McKAY Gerardo (PICCORO)
> > >> http://qgqlochekone.blogspot.com
> > >>
> > >> 2017-03-15 12:24 GMT-04:00 Simon Slavin <slav...@bigfraud.org>:
> > >>
> > >>>
> > >>> On 15 Mar 2017, at 4:09pm, Dominique Devienne <ddevie...@gmail.com>
> > wrote:
> > >>>
> > >>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith <rsm...@rsweb.co.za>
> wrote:
> > >>> >
> > >>> >> I wonder, sqlite Devs, if a pragma or other adaption (such as the
> > >>> current
> > >>> >> pragma table_info()) or such could produce the same exact data but
> > with
> > >>> an
> > >>> >> added field called "Comment" that simply gives the parsed comment
> > from
> > >>> >> after each column definition (if any) like the above table
> example.
> > This
> > >>> >> would probably be a very small adaptation, be completely backwards
> > >>> >> compatible, doesn't break any standard (since there isn't any) and
> > >>> answer
> > >>> >> the need expressed by this thread and others before it.
> > >>> >
> > >>> > That's one way to solve it, in a mostly BC (Backward Compatible)
> way.
> > >>> > (modulo the output from table_info() changing, which could be
> opt-in
> > to
> > >>> > make it fully BC).
> > >>>
> > >>> Problem is, it requires parsing the CREATE command looking for
> > comments in
> > >>> a certain format.  Notoriously difficult, considering that they can
> > contain
> > >>> CR, LF, tab, and unforeseen Unicode characters.
> > >>>
> > >>> I’m utterly against anything that tries to read C-style comments.
> > >>> Comments are comments.  Computers are meant to ignore them to the
> point
> > >>> that they don’t even know they exist.
> > >>>
> > >>> On the other hand, if we establish a standard for storing comments in
> > >>> database tables — which would require a consistent table name, column
> > >>> names, and values — it might take too much extra time to show those
> > >>> comments as an extra column in the response to PRAGMA tale_info() and
> > >>> similar PRAGMAs.  But I think it’s overkill.  Anyone who would want
> > that
> > >>> would know how to retrieve the information.
> > >>>
> > >>> Simon.
> > >>> ___
> > >>> sqlite-users mailing list
> > >>> sqlite-users@mailinglists.sqlite.org
> > >>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > >>>
> > >> ___
> > >> sqlite-users mailing list
> > >> sqlite-users@mailinglists.sqlite.org
> > >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > > ___
> > > sqlite-users mailing list
> > > sqlite-users@mailinglists.sqlite.org
> > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

the problem its that for making some noise or request users must
register, send email, waith response aproval.. too complicated
processs.. that's the reason
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar <dkk...@gmail.com>:
> Patches are still welcome, I guess. I haven't seen anybody claiming
> that this would be done in any way.
>
> On 6 June 2017 at 15:17, PICCORO McKAY Lenz <mckaygerh...@gmail.com> wrote:
>> how its the status of this work?
>>
>> a limited implementation will be good!
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>>
>> 2017-03-15 12:24 GMT-04:00 Simon Slavin <slav...@bigfraud.org>:
>>
>>>
>>> On 15 Mar 2017, at 4:09pm, Dominique Devienne <ddevie...@gmail.com> wrote:
>>>
>>> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith <rsm...@rsweb.co.za> wrote:
>>> >
>>> >> I wonder, sqlite Devs, if a pragma or other adaption (such as the
>>> current
>>> >> pragma table_info()) or such could produce the same exact data but with
>>> an
>>> >> added field called "Comment" that simply gives the parsed comment from
>>> >> after each column definition (if any) like the above table example. This
>>> >> would probably be a very small adaptation, be completely backwards
>>> >> compatible, doesn't break any standard (since there isn't any) and
>>> answer
>>> >> the need expressed by this thread and others before it.
>>> >
>>> > That's one way to solve it, in a mostly BC (Backward Compatible) way.
>>> > (modulo the output from table_info() changing, which could be opt-in to
>>> > make it fully BC).
>>>
>>> Problem is, it requires parsing the CREATE command looking for comments in
>>> a certain format.  Notoriously difficult, considering that they can contain
>>> CR, LF, tab, and unforeseen Unicode characters.
>>>
>>> I’m utterly against anything that tries to read C-style comments.
>>> Comments are comments.  Computers are meant to ignore them to the point
>>> that they don’t even know they exist.
>>>
>>> On the other hand, if we establish a standard for storing comments in
>>> database tables — which would require a consistent table name, column
>>> names, and values — it might take too much extra time to show those
>>> comments as an extra column in the response to PRAGMA tale_info() and
>>> similar PRAGMAs.  But I think it’s overkill.  Anyone who would want that
>>> would know how to retrieve the information.
>>>
>>> Simon.
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@mailinglists.sqlite.org
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

how its the status of this work?

a limited implementation will be good!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-03-15 12:24 GMT-04:00 Simon Slavin :

>
> On 15 Mar 2017, at 4:09pm, Dominique Devienne  wrote:
>
> > On Wed, Mar 15, 2017 at 4:57 PM, R Smith  wrote:
> >
> >> I wonder, sqlite Devs, if a pragma or other adaption (such as the
> current
> >> pragma table_info()) or such could produce the same exact data but with
> an
> >> added field called "Comment" that simply gives the parsed comment from
> >> after each column definition (if any) like the above table example. This
> >> would probably be a very small adaptation, be completely backwards
> >> compatible, doesn't break any standard (since there isn't any) and
> answer
> >> the need expressed by this thread and others before it.
> >
> > That's one way to solve it, in a mostly BC (Backward Compatible) way.
> > (modulo the output from table_info() changing, which could be opt-in to
> > make it fully BC).
>
> Problem is, it requires parsing the CREATE command looking for comments in
> a certain format.  Notoriously difficult, considering that they can contain
> CR, LF, tab, and unforeseen Unicode characters.
>
> I’m utterly against anything that tries to read C-style comments.
> Comments are comments.  Computers are meant to ignore them to the point
> that they don’t even know they exist.
>
> On the other hand, if we establish a standard for storing comments in
> database tables — which would require a consistent table name, column
> names, and values — it might take too much extra time to show those
> comments as an extra column in the response to PRAGMA tale_info() and
> similar PRAGMAs.  But I think it’s overkill.  Anyone who would want that
> would know how to retrieve the information.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] RIGHT JOIN! still not supported?

[PICCORO McKAY Lenz]

i got this

Query Error: RIGHT and FULL OUTER JOINs are not currently supported
Unable to execute statement

still today in 21 ts century?

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite with Java

[PICCORO McKAY Lenz]

one solution its use the odbc sqlite brigde

http://www.java2s.com/Tutorial/Java/0340__Database/ConnecttoAccessDatabaseusingJDBCODBCbridge.htm

with the sqlite odbc module

http://www.ch-werner.de/sqliteodbc/

so due i dont see here java (a general great widely use due
portability) facilities, and too much .net facilities

the other its used 3dr party as:
http://www.sqlitetutorial.net/sqlite-java/

that's enough info
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


2017-03-17 17:35 GMT-04:00 Sylvain Pointeau :
> Dear all,
>
> I would like to use sqlite from Java, but I am also looking to buy SSE.
> however which library would you recommend? how to integrate SSE?
>
> ps: it would be splendid if you could provide the java libs, similar to the
> .net version.
>
> Best regard,
> Sylvain
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

2017-03-15 12:24 GMT-04:00 Simon Slavin :

> Problem is, it requires parsing the CREATE command looking for comments in
> a certain format.  Notoriously difficult, considering that they can contain
> CR, LF, tab, and unforeseen Unicode characters.
>
well limit the comment to 255 chars and if any other non valid were found,
ignore it! like tabs, newlines, etc.. truncate


> I’m utterly against anything that tries to read C-style comments.
> Comments are comments.  Computers are meant to ignore them to the point
> that they don’t even know they exist.
>
> On the other hand, if we establish a standard for storing comments in
> database tables — which would require a consistent table name, column
> names, and values — it might take too much extra time to show those
> comments as an extra column in the response to PRAGMA tale_info() and
> similar PRAGMAs.  But I think it’s overkill.  Anyone who would want that
> would know how to retrieve the information.
>
and if db's configure it to by default do not show this "extra" information?


>
> Simon.
> _default do not show this "extra" _
> _
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

2017-03-15 11:49 GMT-04:00 R Smith :

> Well, the advantage of having comments in DB tables (as some suggested) is
> also that you have the entire SQL language functions available to
> manipulate the comments

that's one firts reason that rely on the second, comment can handle (with
the DBMS) the build in necesary documentation selft conained inside on the
DB, that its helfull for all, (very)


> - which you don't have when they are treated like Meta-data.
> That said, only some DBs include comment in-schema specifiers, like
> Postgres and MySQL as Richard pointed out,

make this in master db can make obvously incompatible and can made grow the
size depends of the comment size and amount of the tables and columns..
but, taking in considerations that today nobody of us take care about that
(machines are so powerfully right?) so makin a extra schema its enought


> Your request has been noted, Thank you for the suggestion.
>
many thanks! really appreciated!

this request was made prevously by another person, see archives.. many many
years ago
also was widelly requested in internet network by many years, but due the
very complicated behavior of the request / bugtraking system for sqlite..
no much was received here


> in MSSQL you have to add a comment by a whole other mechanism.

??? in my job we have complete SQL SERVER 2014 SP1 and performance need a
complete dell r600 and usage of the compelte 1T of RAM need extra
licences.. and more extra and extra "integrations" and then u mention that:

> Easy sailor... There is no need for you use that specific "stupid guindows
> tool", it's simply that the tool had solved the comment problem by parsing
> the schema, and you could do something like it.
>
we use (again) MS-like soft due "recomended", these king of
"recomendations" was the reason of the problem.. we have to paid, mid-usage
of a software we cannot migrate easy now! and we cannot use "complete"
today without a "grow-deep" dependence of the MS ...
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

the idea its that many tools generated (due portability and compability)
sql script with a optional keyword COMMENT on each column definition..

this its xxtremely usefull for selft container documentation for many
console users and rapid development

so manual comment using C-like cannot do that, if i have a large set of
DB's with minimal of 20 tables, its widelly tedious manage comments in that
way that some here sugest me.. and later joint the db files for work?

.. and stop of recomend me stupid guindows tools like sqlitespeed, does not
sqlite are Public Domain thanks god and aliens, but i hate all the
protected breaking-portability like all the guindows progs, the main reason
that's why we have problems porting apps

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-03-15 11:05 GMT-04:00 Richard Hipp :

> On 3/15/17, Simon Slavin  wrote:
> >
> > It’s common to see a four column table, with the columns being
> >
> > entityType
> > theTable
> > theName
> > theComment
> >
>
> This approach has the advantage of being portable across *all* SQL
> database engines, whereas the COMMENT ON command is (as far as I could
> discern from Google) only available on Oracle and PostgreSQL.   This
> approach also makes the comments easy to introspect from applications,
> and update using general-purpose query tools.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

hey their'e WIDELY USED keyword and practice in all mayor DBMS

so can introduce a feature that converts all parts that have COMMENT '(\*)'
to /* COMMENT */ and stored? in the master part of the Database?

and NOTED THAT no many users comes here due the complicated behavior of
report an issue...

so then some bugs have been her for years due that..

this feature are widelly need for many developers, (make a search in
google) but due the asking for feature request are so complicated.. same
for bug reports

sorry guys but must be better in this behavior

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-03-15 10:27 GMT-04:00 Simon Slavin :

>
> On 15 Mar 2017, at 1:27pm, Brian Curley  wrote:
>
> > The sqlite_master table will always preserve any comments embedded
> between
> > the "CREATE" and ";" keywords for a given table definition. Is this not
> > sufficient?
>
> I always found that interesting.  I would have thought that the parser for
> SQLite would strip out those comments before the stage at which the CREATE
> commands were stored.  However, it’s not true.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

[PICCORO McKAY Lenz]

an important feature in a DB its the column field that gives to developers
metadata info INDEPENDENT of the tecnologies used, due by this way with a
simple text editor in generated script developer can read and use minimal
info for understanding structure ...

its a minimal feature need in a database, for many developers that make
GOOD documentation!


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users