> Sqlite lets us advance our storage
> capabilities into a more flexible world.
Sure, but it's not allways a good thing. Usually one column stores related
data.
Related data mostly have the same type. Entering a value of different type is
an error
which is silently ignored. Allowing different
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 4:08 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You have explained the problem, which is .NET not Sqlite. You have
apparently done a fine job marrying
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 31, 2007 4:08 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> You have explained the problem, which is .NET not Sqlite. You have
> apparently done a f
--- John Stanton <[EMAIL PROTECTED]> wrote:
> Sqlite lets you put in anything as the declared type. "DEAD PARROT",
> "MONGOOSE", "GODZILLA" or "DECIMAL(6,1)" are all acceptable declared
> types. Sqlite makes the underlying type TEXT if it is not obviously
> numeric.
The default affinity type
John Stanton wrote:
Sqlite lets you put in anything as the declared type. "DEAD PARROT",
"MONGOOSE", "GODZILLA" or "DECIMAL(6,1)" are all acceptable declared
types. Sqlite makes the underlying type TEXT if it is not obviously
numeric.
Thanks for the clarification. I wasn't aware of that.
John Elrick wrote:
John Stanton wrote:
John Elrick wrote:
SNIP
Introspection would occur via this mechanism and would even move all
introspection for any given system behind a common interface.
Just a thought.
John Elrick
CREATE TABLE already stores the type as its declared type. Th
John Elrick schrieb:
John Stanton wrote:
John Elrick wrote:
SNIP
Introspection would occur via this mechanism and would even move all
introspection for any given system behind a common interface.
Just a thought.
John Elrick
CREATE TABLE already stores the type as its declared type. The
John Stanton wrote:
John Elrick wrote:
SNIP
Introspection would occur via this mechanism and would even move all
introspection for any given system behind a common interface.
Just a thought.
John Elrick
CREATE TABLE already stores the type as its declared type. The user
has that availa
John Elrick wrote:
Michael Schlenker wrote:
A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine,
Michael Schlenker wrote:
A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine, the non-standard
typele
particular concept like .NET would be a tragedy.
You might consider developing an SQL engine ideally adapted to .NET.
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 3:56 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re
A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine, the non-standard
typelessness is something that h
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
> SQLite's typelessness is an asset if you work only with SQLite
> but in any application that uses multiple database engines of
> which SQLite is only one supported engine, the non-standard
> typelessness is something that has to be worked a
[EMAIL PROTECTED]
Sent: Wednesday, May 30, 2007 12:04 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Re: CAST
> I for one would be in favor of an option to enforce strict
> typing (compile time option).
"SQLite version 3 will feature two other affinity modes, as follows:
Strict affinity
> I for one would be in favor of an option to enforce strict
> typing (compile time option).
"SQLite version 3 will feature two other affinity modes, as follows:
Strict affinity mode. In this mode if a conversion between storage classes is
ever required, the database engine returns an error and
Samuel R. Neff schrieb:
SQLite's typelessness is an asset if you work only with SQLite but in any
application that uses multiple database engines of which SQLite is only one
supported engine, the non-standard typelessness is something that has to be
worked around. I for one would be in favor of
-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 6:56 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You are looking for a fit to one particular restrictive, proprietary
environment. Our approach has been to work with the spirit of Sqlite
and to its
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 29, 2007 3:56 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> You are looking for a fit to one particular restrictive, proprietary
> environment. Our a
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 8:40 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You have just given an excellent explanation of why the wrapper
approach
is flawed. Think about it
Don
- Original Message -
From: "Samuel R. Neff" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, May 29, 2007 11:06 AM
Subject: RE: [sqlite] Re: CAST
Actually I'd say he gave a great explanation of why the wrapper approach is
so important. Robert went through all the work t
l Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 11:40 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You have just given an excellent explanation of why the wrapper approach
i
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 29, 2007 8:40 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> You have just given an excellent explanation of why the wrapper
> approach
> is flaw
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 6:18 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
Your comments endorse the approach we took which was to avoid the
wrapper concept entirely with its
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 29, 2007 6:18 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> Your comments endorse the approach we took which was to avoid the
> wrapper concept en
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Monday, May 28, 2007 4:21 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
We actually do that with our Sqlite interfaces. We use the declared
type to specify the type and perform a
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 28, 2007 4:21 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> We actually do that with our Sqlite interfaces. We use the declared
> type to specif
on that "changes the datatype".
- Original Message -
From: "Igor Tandetnik" <[EMAIL PROTECTED]>
To: "SQLite"
Date: Mon, 28 May 2007 10:36:50 -0400
Subject: [sqlite] Re: CAST
[EMAIL PROTECTED] wrote:
I'm wandering if CAST is supposed to work?
Ye
Robert Simpson wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, May 28, 2007 9:11 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
SQLite does not have a dedicated DATE type.
I know that, but why it does't create approp
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 28, 2007 9:11 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
>
> > SQLite does not have a dedicated DATE type.
>
> I know that, but why it
quot;Igor Tandetnik" <[EMAIL PROTECTED]>
To: "SQLite"
Date: Mon, 28 May 2007 10:36:50 -0400
Subject: [sqlite] Re: CAST
> [EMAIL PROTECTED] wrote:
> > I'm wandering if CAST is supposed to work?
>
> Yes.
>
> > sqlite> create table tab(col date)
[EMAIL PROTECTED] wrote:
I'm wandering if CAST is supposed to work?
Yes.
sqlite> create table tab(col date);
sqlite> insert into tab values('1994-11-11');
sqlite> create table tab2 as select cast(col as DATE) from tab;
sqlite> .schema tab2
CREATE TABLE tab2("cast(col as DATE)");
sqlite> selec
31 matches
Mail list logo
