Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Wed, 05 Mar 2008 09:44:21 +0100, Marco Wobben
<[EMAIL PROTECTED]> wrote:
>A brief history:

Thanks much for the information.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 4 Mar 2008 14:33:06 -0800 (PST), Rael Bauer
<[EMAIL PROTECTED]> wrote:
>  This type of question may better be answered on borland forums.

I doubt it. Few Delphi developpers seem to work with SQLite :-/

>  Maybe this will work. all events point to this published method:

Thanks for the code.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 04 Mar 2008 23:07:15 -0600, "Fred Williams"
<[EMAIL PROTECTED]> wrote:
>You might want to test a little further with Aducom's stuff. I'm using
>Aducom and have the following working code in at least one app:
>
>begin
>  AList.Fields.FieldByName(FldName[j+1]).Value :=
>Trim(ExtractData(RS));
>  if RP >= Length(RS) then
>   break;
>end;

Thanks for the code. I don't know what RS and RP are, and how to put
this in a test program, but I'll google for it.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Marco Wobben]

A brief history:

There used to be a size limitation in dBase and perhaps Paradox. 
Traditionally this was supported within the Borland Database Engine. In 
the Delphi components this resolved in text fields and memo fields. The 
Borland Database Engine (BDE) and the components within Delphi. From 
this size limit (probably 255 characters) the field types are set into 
the component layer.

I've written a dbExpress driver for Delphi 6, and working a version for 
DbExpress4 (Delphi 2007) which has a preference which can be set. Using 
this preference you are allows to implement longer texts as memo's or 
keep them as strings. Either way the application needs to know when to 
switch display behaviour. Some programming needs may still be required.

It may be that SQLite's BLOB support may be a better way to solve this 
in the end. I haven't really looked at that yet. In any case it is the 
Connector or Driver on top of SQLite which determines the actual field 
type into the component layer of Delphi. This is what the DbExpress 
driver is supposed to do, translate the database specifics into Delphi 
specifics (and back).

Regards,
Marco.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Fred Williams]

You might want to test a little further with Aducom's stuff. I'm using
Aducom and have the following working code in at least one app:

begin
  AList.Fields.FieldByName(FldName[j+1]).Value :=
Trim(ExtractData(RS));
  if RP >= Length(RS) then
   break;
end;

Fred

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Gilles Ganault
> Sent: Tuesday, March 04, 2008 4:08 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?
>
>
> On Tue, 4 Mar 2008 13:43:46 -0800 (PST), Rael Bauer
> <[EMAIL PROTECTED]> wrote:
> >  3. Add code in this event like the following:
> >Text := qryContacts.FieldByName('MyField').AsString;
>
> Thanks for the tip, but Aducom's Table component doesn't have a
> FieldByName property.
>
> procedure TForm1.ASQLite3Table1phones_parentGetText(Sender: TField;
>   var Text: String; DisplayText: Boolean);
> begin
>   //Text := qryContacts.FieldByName('MyField').AsString;
>   Text := ASQLite3Table1.F
> end;
>
> BTW, is there a way to have this event called for all fields, so as
> not to have to copy/paste for every column?
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Rael Bauer]

>procedure TForm1.ASQLite3Table1phones_parentGetText(Sender: TField;
>  var Text: String; DisplayText: Boolean);
>begin
>  //Text := qryContacts.FieldByName('MyField').AsString;
>  Text := ASQLite3Table1.F
>end;
   
  This property doesn't come up by code completion - but it is there.

>BTW, is there a way to have this event called for all fields, so as
>not to have to copy/paste for every column?
   
  This type of question may better be answered on borland forums.
  Maybe this will work. all events point to this published method:
   
  TForm1.MyGetText(Sender: TField;
 var Text: String; DisplayText: Boolean);
  begin
Text := ASQLite3Table1.Fields[Sender.Index].AsString;
  end;



   
-
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 4 Mar 2008 13:43:46 -0800 (PST), Rael Bauer
<[EMAIL PROTECTED]> wrote:
>  3. Add code in this event like the following:
>Text := qryContacts.FieldByName('MyField').AsString;

Thanks for the tip, but Aducom's Table component doesn't have a
FieldByName property.

procedure TForm1.ASQLite3Table1phones_parentGetText(Sender: TField;
  var Text: String; DisplayText: Boolean);
begin
  //Text := qryContacts.FieldByName('MyField').AsString;
  Text := ASQLite3Table1.F
end;

BTW, is there a way to have this event called for all fields, so as
not to have to copy/paste for every column?

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Rael Bauer]

Hi,
   
  First - this relates to original question.
   
  (I'm replying from yahoo, and I don't know how to reply to a specific message 
from a thread. Perhaps someone can tell me how to do that :) )
   
  I think the question relates to the dataset component. Try this to see if it 
solves problem:
  1. Add persistent fields to your dataset (right click -> fields editor -> add 
all fields)
  2. Each field has an event OnGetText. 
  3. Add code in this event like the following:
Text := qryContacts.FieldByName('MyField').AsString;
   
  hth
  Rael

   
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[John Elrick]

Gilles Ganault wrote:
> On Tue, 04 Mar 2008 14:09:51 -0500, John Elrick
> <[EMAIL PROTECTED]> wrote:
>   
>> You can't.  You lose the db aware aspect, but what I'm saying is it 
>> isn't as "bad" as I used to think.
>> 
>
> OK, I don't mind not using DB-aware widgets if you say it's not much
> more work.
>
> So how do you 1) access an SQLite database from Delphi, and 2) how to
> you manage data between the file and a non-DB-aware grid? If you have
> some basic source handy, I could work from there.
>
>   

I would not mind.  I'm supplying someone else with our libraries and 
will create a simple "Hello World" ap to display some basic concepts.

>> TDataSource/TDataLink was a good idea in its time, but it is way out of 
>> date and, in my experience, creates as many problems as it solves once 
>> you start building more complex user-centric GUIs.
>> 
>
> Yup, that's the impression I get, based on the little I've gathered
> here and there about Delphi and databases.
>   

Still better than the MS world  I will remember to my dying day the 
time I discovered a rather troublesome defect when calling AddNew on the 
DataControl in VB 5.0 when tied to a Sheridan grid.  It blue screened my OS.


John
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 04 Mar 2008 14:09:51 -0500, John Elrick
<[EMAIL PROTECTED]> wrote:
>You can't.  You lose the db aware aspect, but what I'm saying is it 
>isn't as "bad" as I used to think.

OK, I don't mind not using DB-aware widgets if you say it's not much
more work.

So how do you 1) access an SQLite database from Delphi, and 2) how to
you manage data between the file and a non-DB-aware grid? If you have
some basic source handy, I could work from there.

>TDataSource/TDataLink was a good idea in its time, but it is way out of 
>date and, in my experience, creates as many problems as it solves once 
>you start building more complex user-centric GUIs.

Yup, that's the impression I get, based on the little I've gathered
here and there about Delphi and databases.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[John Elrick]

Gilles Ganault wrote:
>
>> We haven't used TDataSource in quite some time and actually don't miss it.  
>> 
>
> I didn't know you could do away with all those components to connect
> DB-aware widgets. If you have some DelphiWin32 "hello, world" sort of
> code, I'm very interested :-)
>   

You can't.  You lose the db aware aspect, but what I'm saying is it 
isn't as "bad" as I used to think.

>   
>> Although for years I was concerned about the cost in programmer time of 
>> using disconnected components, I've found the gains from using 
>> TDataSource are outweighed by the non-deterministic behavior of the data 
>> connections.
>> 
>
> Care to be more specific? In short, what are the drawbacks about using
> Table/Query + DataSource?
>   


The primary source of non-determinism is that the user tends to get 
involved.  Most code is triggered by events, which works up to a point.  
Once the model breaks down, it does so in a way which cannot be easily 
worked around.  I can recall many times having to stick convoluted logic 
to handle the case of one field being updated which causes other data to 
be affected.  By going to a non data-aware model, all those issues 
disappear because your posting logic becomes 100% deterministic.  There 
are no side effects due to events firing off.

As a generic example, if you attach something like a grid to a table, 
you must either maintain an open connection to the table or transfer the 
data into a memory table.  Keeping a live connection is potentially 
dangerous and memory consumptive.  Using a memory table is useful in 
small circumstances, but once you reach a certain amount of rows, you 
end up writing caching code to maintain performance.

For this example, the solution I've found which works is to have a 
non-data aware grid in virtual mode.  The system uses a data supply 
model which figures out what is to be displayed and supplies it to the 
grid on demand.  It's scary at first, because you feel like you are 
re-inventing the wheel, but you quickly find out you are not.  
TDataSource/TDataLink was a good idea in its time, but it is way out of 
date and, in my experience, creates as many problems as it solves once 
you start building more complex user-centric GUIs.

FWIW

John Elrick
Fenestra Technologies
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 4 Mar 2008 11:39:40 -0600, "P Kishor"
<[EMAIL PROTECTED]> wrote:
>I think you really need to read 

I did. The problem is not SQLite, it's the connector (Delphi, in this
case). If I knew how and I could still use DB-aware grids, I would
gladly get rid of this and SQLite directly.

>In some ways, Richard has spoiled me. After using SQLite, every other
>db is a chore. It gives me complete control to do what I want to, and
>does exceedingly well what it claims to... return my data to me
>incredibly fast when I query it. My logic is in my application.

I always wondered how SQLite can offer such great performance with
just two types (numeric and text) and not having to specify the length
of each column, while other DBMS's are such a pain with this.

>I don't know what you mean by "active development" as DBD::SQLite is
>under very active development, in the sense that it gets updated
>occasionally.

We're talking Delphi, not Perl ;)

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 04 Mar 2008 12:43:30 -0500, John Elrick
<[EMAIL PROTECTED]> wrote:
>The component.  We used Aducom for a while and found that TEXT is 
>internally converted to a TMemo field.  If you examine the source, you 
>can see the conversions.

OK, so Aducom is out. I'll give DISQLite a deeper look, and it this
one has the same issue...

> We haven't used TDataSource in quite some time and actually don't miss it.  

I didn't know you could do away with all those components to connect
DB-aware widgets. If you have some DelphiWin32 "hello, world" sort of
code, I'm very interested :-)

>Although for years I was concerned about the cost in programmer time of 
>using disconnected components, I've found the gains from using 
>TDataSource are outweighed by the non-deterministic behavior of the data 
>connections.

Care to be more specific? In short, what are the drawbacks about using
Table/Query + DataSource?

Thanks.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[John Elrick]

Gilles Ganault wrote:
> On Tue, 04 Mar 2008 09:27:14 -0500, John Elrick
> <[EMAIL PROTECTED]> wrote:
>   
>> FYI, we rolled our own adapters for a Delphi project.  We had no use for 
>> the TDataset capabilities and removed the overhead.  I would be happy to 
>> share them if they would help.
>> 
>
> I haven't found a good guide/tutorial on Delphi and databases, so I'm
> still a bit in the dark as to how all those parts work together, so I
> have a couple of questions for you:
> - What is the cause of grids showing MEMO instead of the actual
> strings defined as TEXT in SQLite? Is it the grid itself, or the
> Delphi component to SQLite (Aducom, in this case)?
>   

The component.  We used Aducom for a while and found that TEXT is 
internally converted to a TMemo field.  If you examine the source, you 
can see the conversions.

> - DataSet = either the Table or Query components? If they're removed
> from the equation, what are the consequences (performance, features,
> connecting the DataSource/DB* components to the SQLite file, etc.)?
>   

Correct, basically any TDataset descendant.  Performance improves 
dramatically in most cases due to the fine tuning on data retrieval.  We 
haven't used TDataSource in quite some time and actually don't miss it.  
Although for years I was concerned about the cost in programmer time of 
using disconnected components, I've found the gains from using 
TDataSource are outweighed by the non-deterministic behavior of the data 
connections.

Our application uses an MVC variant to separate the concerns between the 
presentation, the model, and the controller.


HTH


John
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[P Kishor]

On 3/4/08, Gilles Ganault <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Mar 2008 11:03:44 -0600, "P Kishor"
>  <[EMAIL PROTECTED]> wrote:
>  >I think that was the point of my saying, "Anything using SQLite is
>  >free to do what it wants." I routinely write Perl code that checks
>  >what I am inserting into SQLite and croaks if something is not as I
>  >expected.
>
>  So, even though SQLite only differentiates between numeric and text,
>  connectors for such and such language might be more rigid, and have an
>  issue with TEXT.

I think you really need to read 

SQLite doesn't differentiate anything, although you can make it do so
with CHECK CONSTRAINTS or with your own code. If you insist on shoving
numbers in text or text in numbers or music or photos or molecular
structures in varchar, SQLite will happily comply. The following, for
example, is a valid SQLite schema

[02:45 PM] ~$ sqlite3 foo.db
SQLite version 3.5.6
Enter ".help" for instructions
sqlite> CREATE TABLE magic (a ELEPHANT, b TIGER, c AIRPLANE);
sqlite> INSERT INTO magic (a, b, c) VALUES ('punkish', 234, '*&*^%^&');
sqlite> SELECT * FROM magic;
punkish|234|*&*^%^&
sqlite> .s
CREATE TABLE magic (a ELEPHANT, b TIGER, c AIRPLANE);
sqlite>


In some ways, Richard has spoiled me. After using SQLite, every other
db is a chore. It gives me complete control to do what I want to, and
does exceedingly well what it claims to... return my data to me
incredibly fast when I query it. My logic is in my application.



>
>  I only know of two connectors for SQLite3 in active development:
>  Aducom, and DISQLite. I haven't successfully used the latter yet, so
>  don't know if it also has the MEMO issue with TEXT.
>

I don't know what you mean by "active development" as DBD::SQLite is
under very active development, in the sense that it gets updated
occasionally. Same is likely true for Python or PHP "connectors."

Although others using the same connectors on this list might be able
to assist, you would likely get more directed help on deeper
"connector" issues on those connector mailing lists, if they have any.

Puneet.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 4 Mar 2008 11:03:44 -0600, "P Kishor"
<[EMAIL PROTECTED]> wrote:
>I think that was the point of my saying, "Anything using SQLite is
>free to do what it wants." I routinely write Perl code that checks
>what I am inserting into SQLite and croaks if something is not as I
>expected.

So, even though SQLite only differentiates between numeric and text,
connectors for such and such language might be more rigid, and have an
issue with TEXT.

I only know of two connectors for SQLite3 in active development:
Aducom, and DISQLite. I haven't successfully used the latter yet, so
don't know if it also has the MEMO issue with TEXT.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 04 Mar 2008 09:27:14 -0500, John Elrick
<[EMAIL PROTECTED]> wrote:
>FYI, we rolled our own adapters for a Delphi project.  We had no use for 
>the TDataset capabilities and removed the overhead.  I would be happy to 
>share them if they would help.

I haven't found a good guide/tutorial on Delphi and databases, so I'm
still a bit in the dark as to how all those parts work together, so I
have a couple of questions for you:
- What is the cause of grids showing MEMO instead of the actual
strings defined as TEXT in SQLite? Is it the grid itself, or the
Delphi component to SQLite (Aducom, in this case)?
- DataSet = either the Table or Query components? If they're removed
from the equation, what are the consequences (performance, features,
connecting the DataSource/DB* components to the SQLite file, etc.)?

Thank you.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[P Kishor]

On 3/4/08, John Elrick <[EMAIL PROTECTED]> wrote:
> P Kishor wrote:
>  > I think you have answered you question yourself. See below --
>  >
>  > On 3/4/08, Gilles Ganault <[EMAIL PROTECTED]> wrote:
>  >
>  >> Hello
>  >>
>  >> I thought that SQLite treated any numeric data the same, but some
>  >>  Delphi components seem to handle TEXT data as BLOB/MEMO, and handle
>  >>  VARCHAR as regular text:
>  >>
>  >
>  > SQLite doesn't care. Anything using SQLite is free to do what it wants.
>
>
> SQLite doesn't care.  I can testify from experience that some of the
>  Delphi wrappers DO care and artificially enforce the VARCHAR length.
>


I think that was the point of my saying, "Anything using SQLite is
free to do what it wants." I routinely write Perl code that checks
what I am inserting into SQLite and croaks if something is not as I
expected.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[John Elrick]

P Kishor wrote:
> I think you have answered you question yourself. See below --
>
> On 3/4/08, Gilles Ganault <[EMAIL PROTECTED]> wrote:
>   
>> Hello
>>
>> I thought that SQLite treated any numeric data the same, but some
>>  Delphi components seem to handle TEXT data as BLOB/MEMO, and handle
>>  VARCHAR as regular text:
>> 
>
> SQLite doesn't care. Anything using SQLite is free to do what it wants.

SQLite doesn't care.  I can testify from experience that some of the 
Delphi wrappers DO care and artificially enforce the VARCHAR length.


John
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[P Kishor]

I think you have answered you question yourself. See below --

On 3/4/08, Gilles Ganault <[EMAIL PROTECTED]> wrote:
> Hello
>
> I thought that SQLite treated any numeric data the same, but some
>  Delphi components seem to handle TEXT data as BLOB/MEMO, and handle
>  VARCHAR as regular text:

SQLite doesn't care. Anything using SQLite is free to do what it wants.

>
>  http://img404.imageshack.us/img404/8614/nextdbgridparentzt9.jpg
>  http://img246.imageshack.us/img246/6615/delphismdbgrid1hw8.jpg
>
>  I'd like to know if there are drawbacks to switching from TEXT to
>  (VAR)CHAR? I'd rather not have to specify the maximum length of text
>  items because I usually don't know how bit they might be.
>

Once again, SQLite doesn't care and will happily store a million
character string in a TEXT (1) column.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[John Elrick]

Gilles Ganault wrote:
> On Tue, 4 Mar 2008 09:00:31 -0500, "Igor Tandetnik"
> <[EMAIL PROTECTED]> wrote:
>   
>> There's no difference as far as SQLite is concerned. Length 
>> specification, if present, is parsed but not enforced.
>> 
>
> Yes, that's what I read too, but obviously, like Apple, some component
> in Delphi think different :-)
>
> I'll try a different SQLite connector, and if it still doesn't work,
> I'll convert all the tables from TEXT to VARCHAR without specifying
> the number of characters.
>   

FYI, we rolled our own adapters for a Delphi project.  We had no use for 
the TDataset capabilities and removed the overhead.  I would be happy to 
share them if they would help.


John
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Gilles Ganault]

On Tue, 4 Mar 2008 09:00:31 -0500, "Igor Tandetnik"
<[EMAIL PROTECTED]> wrote:
>There's no difference as far as SQLite is concerned. Length 
>specification, if present, is parsed but not enforced.

Yes, that's what I read too, but obviously, like Apple, some component
in Delphi think different :-)

I'll try a different SQLite connector, and if it still doesn't work,
I'll convert all the tables from TEXT to VARCHAR without specifying
the number of characters.

Thank you.

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

Re: [sqlite] [Delphi7] TEXT vs. (VAR)CHAR?

[Igor Tandetnik]

"Gilles Ganault" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
> I'd like to know if there are drawbacks to switching from TEXT to
> (VAR)CHAR?

There's no difference as far as SQLite is concerned. Length 
specification, if present, is parsed but not enforced. For more details, 
see

http://sqlite.org/datatype3.html

Igor Tandetnik



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