e-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Adam Devita
> Sent: Monday, 18 April, 2016 13:45
> To: SQLite mailing list
> Subject: Re: [sqlite] Primary key values can be NULL
>
> I had a similar thought, until I imagined
>
> Program uses sqlite DLL
> The progr
I don't mean to poke a busy thread with a possibly stupid newbie question, but
here goes.
How is this that much different than say, the SQLITE_DEFAULT_FILE_FORMAT
compile option? (Pasting it here then continuing comment below)
Text pasted here
SQLITE_DEFAULT_FILE_FORMAT=<1 or 4>
I had a similar thought, until I imagined
Program uses sqlite DLL
The program creates dbs, and sometimes does inserts with null primary
keys. (Why is beyond the scope, it just does sometimes.)
Upgrading the DLL would start making files in the new format, but the
program using the dll doesn't
2016-04-15 22:36 GMT+02:00 Cecil Westerhof :
> ?I use it for logging. It is much easier to find something, or delete the
> parts you do not need anymore.
>
An example:
https://www.linkedin.com/pulse/use-bash-store-disc-info-sqlite-cecil-westerhof
If I could do things better: let me know.
--
2016-04-15 22:04 GMT+02:00 R Smith :
?I do not think it is. When you add something to the database to signify
>> that a primary key is not allowed to be NULL, then this is not in an old
>> database, ergo in the old database NULLs are allowed. Where does backward
>> compatibility get broken? As I
On 2016/04/15 8:00 PM, Cecil Westerhof wrote:
> 2016-04-15 16:43 GMT+02:00 R Smith :
>
>
> ?Do you want me to tell you that you always read all the documentation of
> all the software before you use it? I surely do not. And I think most
> people do not. To be honest I think you do also not: it
2016-04-15 20:10 GMT+02:00 John McKown :
> On Fri, Apr 15, 2016 at 1:00 PM, Cecil Westerhof
> wrote:
> ??
>
>
> >
> > ?I do not think it is. When you add something to the database to signify
> > that a primary key is not allowed to be NULL, then this is not in an old
> > database, ergo in the
2016-04-15 16:43 GMT+02:00 R Smith :
>
>
> On 2016/04/15 2:09 PM, Cecil Westerhof wrote:
>
>> If you go to:
>> https://www.sqlite.org/lang_createtable.html
>>
>> You will find:
>> According to the SQL standard, PRIMARY KEY should always
>> imply NOT NULL. Unfortunately, due to a
On 2016/04/15 2:09 PM, Cecil Westerhof wrote:
>
>> What makes you "expect" this? Nothing in the SQLite documentation I hope.
>>> Is it perhaps habit based on how some other DBs do it?
>>>
>>> How will "those who don't know about NOT NULL" be better serviced by a
>>> pragma which they also don't
On Fri, Apr 15, 2016 at 3:04 PM, R Smith wrote:
>
> That's great news :)
> Let me just note that we do not really shun the likes of Postgress, MSSQL,
> MySQL etc. - those systems answer a different need. If you for instance
> want to store secret information with per-table user access controls,
2016-04-15 1:19 GMT+02:00 J Decker :
> I would total expect any column I created without NOT NULL (double
> negative) to allow NULL whether INDEX or UNIQUE or PRIMARY is applied
> additionallywhat database does otherwise? MSSQL?
>
?Every database that is not SQLite, because it is the
2016-04-15 1:19 GMT+02:00 J Decker :
> I would total expect any column I created without NOT NULL (double
> negative) to allow NULL whether INDEX or UNIQUE or PRIMARY is applied
> additionallywhat database does otherwise? MSSQL?
>
> On Thu, Apr 14, 2016 at 2:56 PM, R Smith wrote:
> >
> >
>
On Fri, Apr 15, 2016 at 1:00 PM, Cecil Westerhof
wrote:
??
>
> ?I do not think it is. When you add something to the database to signify
> that a primary key is not allowed to be NULL, then this is not in an old
> database, ergo in the old database NULLs are allowed. Where does backward
>
On Fri, 15 Apr 2016 14:13:12 +0200
Cecil Westerhof wrote:
> 2016-04-15 1:19 GMT+02:00 J Decker :
>
> > I would total expect any column I created without NOT NULL (double
> > negative) to allow NULL whether INDEX or UNIQUE or PRIMARY is
> > applied additionallywhat database does otherwise?
On 2016/04/14 10:23 PM, Cecil Westerhof wrote:
> 2016-04-14 22:10 GMT+02:00 Richard Hipp :
>
>> On 4/14/16, Cecil Westerhof wrote:
>>> ?Yes that makes sense. But could not a type of PRAGMA be used? So if the
>>> PRAGMA is not defined the old functionality and your historical data is
>>> save.
2016-04-14 22:10 GMT+02:00 Richard Hipp :
> On 4/14/16, Cecil Westerhof wrote:
> >
> > ?Yes that makes sense. But could not a type of PRAGMA be used? So if the
> > PRAGMA is not defined the old functionality and your historical data is
> > save. And if the PRAGMA is defined the new
2016-04-14 21:46 GMT+02:00 Richard Hipp :
> On 4/14/16, Cecil Westerhof wrote:
> > For example a database with partial tables can not be read with a
> > SQLite before 3.8.0. So why is SQLite not changed so primary keys can not
> > have the value NULL?
>
> You fail to distinguish between
I was bitten by the fact that values of a primary key can be NULL. I
understood that this is for historical reasons. But there has been a lot of
changes. For example a database with partial tables can not be read with a
SQLite before 3.8.0. So why is SQLite not changed so primary keys can not
have
I would total expect any column I created without NOT NULL (double
negative) to allow NULL whether INDEX or UNIQUE or PRIMARY is applied
additionallywhat database does otherwise? MSSQL?
On Thu, Apr 14, 2016 at 2:56 PM, R Smith wrote:
>
>
> On 2016/04/14 10:23 PM, Cecil Westerhof wrote:
>>
On 4/14/16, Cecil Westerhof wrote:
>
> ?Yes that makes sense. But could not a type of PRAGMA be used? So if the
> PRAGMA is not defined the old functionality and your historical data is
> save. And if the PRAGMA is defined the new functionality.
>
Easier: Just declare the columns in question as
On 4/14/16, Cecil Westerhof wrote:
> For example a database with partial tables can not be read with a
> SQLite before 3.8.0. So why is SQLite not changed so primary keys can not
> have the value NULL?
You fail to distinguish between "forwards compatible" and "backwards
compatible".
Upgrading
21 matches
Mail list logo
