An integer primary key is the only field that absolutely must be the type declared. It basically says to use the internal rowid as a visible field.
Currently it does start at 1 and any newly inserted record where the id is not explicitly specified will get an id of 1 more than whatever's the current highest at the time. Though I believe that's not a standard so much as a "here's how we decided to implement it for now" thing, and thus shouldn't be relied upon. -----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Clyde Eisenbeis Sent: Thursday, February 02, 2017 9:12 AM To: SQLite mailing list Subject: Re: [sqlite] Does SQLite use field definitions? What about the INTEGER PRIMARY KEY (defined in my first email post)? Does this field start at 1, and then auto increment for each new line? On Thu, Feb 2, 2017 at 5:02 AM, R Smith <rsm...@rsweb.co.za> wrote: > > > On 2017/02/01 5:41 PM, Clyde Eisenbeis wrote: >> >> I don't see MEMO listed. I needed to use MEMO in Microsoft Access to >> handle char strings longer than 256. >> >> However, I don't see any complaints by SQLite when I use MEMO. > > > SQLite will never complain about anything you use as a type. What you should > to use is TEXT. In SQLite any string value, of any length* can be stored in > any column, but will be "handled like text" when the column is of the TEXT > type affinity, and also allow a collation method. Honestly, you can put the > text of the complete volumes of Don Quixotic in a single TEXT field in a > database. > > * - As long as the string memory doesn't exceed 4GB, the char-size of which > may differ based on encoding, and if you add the quoted string to the query > text directly (as opposed to binding it via the API), then the maximum size > will be governed by the max character length of the query input, which can > be configured via the API also. You can add the string as memory bytes as a > BLOB to go bigger, but then you lose collation capability.... I'll stop > there, it's probably more unnecessary info than you wished for already. > > > _______________________________________________ > 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
