[sqlite] Is this Sorting order right?

[Mahalakshmi.m]

Igor Tandetnik wrote
>> I can't reproduce this particular problem. Here's the test I wrote:
>> Figure out what you are doing differently.

I too did the same using both UTF8 anf UTF16 .Its coming right for UTF8 but
its wrong for UTF16.

For both encoding I used the below procedure,
sqlite3_prepare(db, "insert into t(id, text) values (?, ?)", -1, 
&insert, 0);

 unsigned short Name[64];
 sqlite3_bind_int(insert, 1, 1);
 sqlite3_bind_text16(insert, 2, Name, -1, SQLITE_STATIC);
 sqlite3_step(insert);

For UTF8 output is
id=2 text=30A2
id=1 text=6B4C
This sorting is as expected.

For UTF16 output is
id=1 text=6B4C
id=2 text=30A2
This sorting is not expected.

Where I was wrong in UTF16 encoding.
Is there any reson for coming in UTF8 and not in UTF16?

Thanks & Regards,
Mahalakshmi



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

Re: [sqlite] Cannot get amalgamation built from CVS to compile

[Samuel Neff]

Matthey,

Thanks for making this change.  We got latest from CVS today and
configure/make worked great.

One other issue we're having and are not sure about is we get a compiler
error on sqlite3_profile and sqlite3_trace.  We need to remove these two
lines from the def file included with the sqlite source in order to get
everything to compile ok on VS 2008.  are sqlite3_profile and sqlite3_trace
included by default in both the source and def or is there a mismatch?  Or
is there something else we should be doing besides editing the def file
manually?

Best regards,

Sam


On Tue, May 6, 2008 at 10:48 PM, Matthew L. Creech <[EMAIL PROTECTED]>
wrote:

> In the latest CVS, you should now also be able to do what you intended
> in the first place.  Namely:
>
> ./configure
> make sqlite3.c
>
> I thought about it, and there's no good reason to inline the
> auto-generated config.h file in to the amalgamation like we were
> doing, so now it keeps it as an #include that's only performed if
> building in-tree.  Let me know if you see any more problems.
>
> --
> Matthew L. Creech
>



-- 
-
We're Hiring! Seeking passionate Flex, C#, or C++ (RTSP, H264) developer.
Position is in the Washington D.C. metro area. Contact
[EMAIL PROTECTED]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Distributed transaction best practices

[David Barrett]

Ah, it sounds like we're building essentially the same thing -- mine is 
also for a financial setting.  You're right, a mirror-replicating mode 
might be adequate, and is certainly simpler...  But part of me is afraid 
that it leaves you vulnerable to failure conditions that a full 
two-phase commit system wouldn't.

For example, I'd like the master to actively reject all transactions 
that aren't committed to at least one slave, else we're operating 
without a net -- if the master is lost during such a period, there is 
unrecoverable data loss.  (And even if the data eventually becomes 
available when the master comes back, until then the backup is 
incomplete and thus putting up a new server is risky.)  I'd rather take 
the service down than risk getting stuck with a huge bill due to an 
accounting error.

As I mentioned, I'm currently just using a serialized two-phase commit 
approach, and that's fine but has very limited throughput. 
Realistically, even that throughput is probably fine to start, but I'd 
like to at least understand the alternatives in case I want to go there 
in the future.

It seems like one alternative might involve undo/redo logs, but I'm not 
quite seeing it.

How does MySQL or Postgres do it?  Does SQLite simply lack some crucial 
feature that is required to do it for real?

-david

Virgilio Alexandre Fornazin wrote:
> The best you can do actually with SQLite is a 'mirror-replicating' mode
> engine
> that works like Microsoft Windows Active Directory Database, to build a king
> of 
> High Availability / Load Balancing server.
> 
> You have a farm of servers (or workstations, etc) receiving SQL commands by
> a 
> channel (socket, pipe, whatever). They force a 'election' do decide what´s
> the
> best servers to become master, then they agree on that and transactions (all
> 
> commands that modify the database) are first applied to the master server
> then
> 'mirrored' to slave servers. In this design, if a 'child' server cannot
> complete
> the transaction that are completed by master and any other server, there is
> a
> critical problem in that slave node, and you must consider it offline or
> some kind of state that you need to check if by hand or by one tool you
> might
> develop for this. In this scenario, you can do a 'load balance' in SELECT´s,
> distributing querying belong all servers, creating affinities for tables, 
> buffering most used tables in a memory database, etc.
> 
> I´m currently implementing services for finantial stock exchanging services
> that
> works in the way I told you, if you are planning something that we can have
> in the
> way SQLite is (not tied to any kind of restrictive license), we can share
> knowledge 
> and implement a solution like that. (PS: I don't have full time to work on
> it, but 
> I can help in free hours)
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Griggs, Donald
> Sent: segunda-feira, 12 de maio de 2008 10:47
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Distributed transaction best practices
> 
> Hi David,
> 
> 
> Regarding:  "What are the recommended "best practices" around using
> SQLite in a distributed scenario?"  [two-phase commit, etc.]
> 
> I trust that someone with some actual relevant knowledge will reply to
> your query later, but I imagine that many would say the the "recommend
> best practice" is *not* to use sqlite, since sqlite was designed to be
> an elegant embedded database -- without even one server -- let alone
> multiple synchronized ones.
> 
> I take it you have strong reasons for rejecting, say, Postgres, which
> now implements two-phase commmit right out of the box?  
>  
> http://www.postgresql.org/docs/current/static/sql-prepare-transaction.ht
> ml
> 
> You may already know everything in articles such as this one
>  
> http://en.wikipedia.org/wiki/Two_phase_commit#Distributed_two-phase_comm
> it_protocol
> And its references (I don't claim to), but I'm listing it here just it
> case it's helpful to you.
> 
> On the other hand, if you *do* develop a solid "distributed sqlite"
> implementation, I'm sure others would be interested.
> 
> Regards,
>   Donald Griggs
> 
>  
> 
> 
> This email and any attachments have been scanned for known viruses using
> multiple scanners. We believe that this email and any attachments are virus
> free, however the recipient must take full responsibility for virus
> checking. 
> This email message is intended for the named recipient only. It may be
> privileged and/or confidential. If you are not the named recipient of this
> email please notify us immediately and do not copy it or use it for any
> purpose, nor disclose its contents to any other person.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> ___
> sqlite-users mailing list
> sqlite

Re: [sqlite] Indexing virtual tables

[Scott Hess]

I'm not quite clear on your question - why wouldn't you just create
any indices you need within the virtual-table implementation itself?
Sort of like how fts uses SQLite tables to implement data-storage for
the full-text index.

-scott


On Mon, May 5, 2008 at 10:13 AM, Aladdin Lampé <[EMAIL PROTECTED]> wrote:
>
> Just thinking again about indexing strategies on virtual tables, I'm 
> wondering why virtual tables could not be indexed using the "normal" SQLite 
> command "INDEX". Indeed, I just expected that the data inside the column of 
> the virtual table could be sequentially scanned (using the "xColumn" 
> callback), producing the same result as if it were a real table. Is that way 
> of seeing things flawed?
>
> Any hook allowing to use SQLite internal indexing techniques for virtual 
> tables? Maybe using direct b-tree manipulation (even if I know it's not 
> recommended)? I'm not very keen on developing my own from stratch. Dealing 
> with "big" tables that don't fit into memory does not seem so easy because 
> I'll have to use a temporary disk file...
>
> Some help would be greatly appreciated!
> Aladdin
>
> _
> Faites vous de nouveaux amis grâce à l'annuaire des profils Messenger !
> http://home.services.spaces.live.com/search/?page=searchresults&ss=true&FormId=AdvPeopleSearch&form=SPXFRM&tp=3&sc=2&pg=0&Search.DisplayName=Nom+public&search.gender=&search.age=&Search.FirstName=Pr%C3%A9nom&Search.LastName=Nom&search.location=Lieu&search.occupation=Profession&search.interests=amis&submit=Rechercher
> ___
> 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] Check the error message

[Teg]

Hello Joanne,

Monday, May 12, 2008, 4:37:29 PM, you wrote:

JP> Hi All,
JP> We have an application in C++ is up and running all the time to
JP> insert the data into the table. At the same time we
JP> have the shell script to dump the database to file at the end of
JP> the hour as defined below in this email.
JP> The question that I have is while the application is writting
JP> data to database and at the same time the bash script is running
JP> to dump the data to the file. At this time the script dump the
JP> data to the file has the protential "database lock(Deadlocked)"
JP> because the application is writting the data to database at the
JP> time of selection. If this the case then how to check the
JP> "database lock" in the bash script.
JP> Thanks,
JP> JL
JP> #!/bin/bash
JP> .sqlite3 CommonDB < $1
JP> ...
JP> $1 is script file as defined below:
JP> 
JP> .output '/tmp/statsData'
JP> .mode csv
JP> select '#RemoteWX';
JP> select remoteId, remoteWXId, hostName, active, remoteWXType from 
remoteWXTable order by remoteId;
JP> select '#RemoteWX';
JP> attach database '/tmp/CompressCurHourDB' as CCHDB;
JP> select * from CCHDB.compressTable;
JP> detach database CCHDB
JP> ...


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


Write another C++ app that does the dump and handles the busy
condition properly and run this from your scripts.

C


JP>  
JP> 

JP> Be a better friend, newshound, and 
JP> know-it-all with Yahoo! Mobile.  Try it now. 
JP> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
JP> ___
JP> sqlite-users mailing list
JP> sqlite-users@sqlite.org
JP> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



-- 
Best regards,
 Tegmailto:[EMAIL PROTECTED]

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

[sqlite] Check the error message

[Joanne Pham]

Hi All,
We have an application in C++ is up and running all the time to insert the data 
into the table. At the same time we
have the shell script to dump the database to file at the end of the hour as 
defined below in this email.
The question that I have is while the application is writting data to database 
and at the same time the bash script is running to dump the data to the file. 
At this time the script dump the data to the file has the protential "database 
lock(Deadlocked)" because the application is writting the data to database at 
the time of selection. If this the case then how to check the "database lock" 
in the bash script.
Thanks,
JL
#!/bin/bash
.sqlite3 CommonDB < $1
...
$1 is script file as defined below:

.output '/tmp/statsData'
.mode csv
select '#RemoteWX';
select remoteId, remoteWXId, hostName, active, remoteWXType from remoteWXTable 
order by remoteId;
select '#RemoteWX';
attach database '/tmp/CompressCurHourDB' as CCHDB;
select * from CCHDB.compressTable;
detach database CCHDB
...



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



  

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

Re: [sqlite] Is this Sorting order right?

[Igor Tandetnik]

Mahalakshmi.m
<[EMAIL PROTECTED]>
wrote:
> What about Japanese Kanji?
> Will sqlite sort all the Hiragana,Katakana,Kanji.
> I am having some records with starting Unicode as follows.
>
> 6B4C  Kanji 25 1
> 30A2  Katakana 
>
> I am storing it using sqlite3_bind_text16().
>
> But if I sort the above two the Unicode with 6B4C comes first but my
> desired output is
>
> 30A2  Katakana
> 6B4C  Kanji   25 1

I can't reproduce this particular problem. Here's the test I wrote:

#include 
#include 

int main() {
  sqlite3* db;
  sqlite3_open(":memory:", &db);

  sqlite3_exec(db, "create table t(id, text)", 0, 0, 0);

  sqlite3_stmt* insert;
  sqlite3_prepare(db, "insert into t(id, text) values (?, ?)", -1, 
&insert, 0);

  sqlite3_bind_int(insert, 1, 1);
  sqlite3_bind_text16(insert, 2, L"\u6B4C", -1, SQLITE_STATIC);
  sqlite3_step(insert);
  sqlite3_reset(insert);

  sqlite3_bind_int(insert, 1, 2);
  sqlite3_bind_text16(insert, 2, L"\u30A2", -1, SQLITE_STATIC);
  sqlite3_step(insert);
  sqlite3_finalize(insert);

  sqlite3_stmt* select;
  sqlite3_prepare(db, "select id, text from t order by text", -1, 
&select, 0);
  while (sqlite3_step(select) == SQLITE_ROW) {
int id = sqlite3_column_int(select, 0);
wchar_t* text = (wchar_t*)sqlite3_column_text16(select, 1);
printf("id=%d text=%X\n", id, (int)text[0]);
  }
  sqlite3_finalize(select);

  sqlite3_close(db);
  return 0;
}



This program prints

id=2 text=30A2
id=1 text=6B4C

meaning that sorting is as expected. Figure out what you are doing 
differently.


Note that, in general, there's more to collation than a simple memcmp 
that SQLite does. Consider for example U+30FD (Katakana Iteration Mark). 
As I understand, a string containing it should sort as if the preceding 
character was actually repeated: so ?? (U+30A2 U+30FD) should sort 
before ?? (U+30A2 U+30A4). Also consider halfwidth letters (e.g. U+FF71 
Halfwidth Katakana Letter A) which are expected to be sorted near their 
fullwidth equivalents.

Igor Tandetnik 



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

Re: [sqlite] Is this Sorting order right?

[Bob Ebert]

Here's an example skeleton for a custom collation.  (Using UTF8
encoding, change the declarations as necessary.)

// declarations
typedef int SQLiteCompare_t (void *, int, const void *, int,
const void *);

int MyCompare(void *userData, int str1Len, const UTF8 *str1, int
str2Len, const UTF8 *str2)
{
// whatever you want here, return < 0 if str1 < str2, 0
if equal, etc.
} 


// connecting the function
int err = sqlite3_create_collation(db, "MyCompare", SQLITE_UTF8,
NULL, (SQLiteCompare_t *)&MyCompare);
if (err != SQLITE_OK)
{
// do something to handle the err -- probably fix your
code, this should work
}


To use, 'CREATE TABLE foo(bar TEXT COLLATE MyCompare);'

Now you're set -- of course keep in mind that if you open the DB with a
different sqlite (e.g. the command line tool or a GUI browser), the
custom collation sequence won't be available.  Sqlite is fairly robust,
it won't blow up and you can still do pretty much anything with the DB
that doesn't directly call the custom function, e.g. don't try to sort
by the "bar" column or use an index built on that column.

--Bob

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mahalakshmi.m
Sent: Monday, May 12, 2008 7:21 AM
To: Sqlite User
Subject: [sqlite] Is this Sorting order right?


Mahalakshmi wrote 
> What about Japanese Kanji?
> Will sqlite sort all the Hiragana,Katakana,Kanji.

Igor Tandetnik wrote

>> Not out of the box. You will have to implement a custom collation. 
>> Or, you can build SQLite with ICU support, then it >> will use ICU 
>> collation functions.

Thanks a lot.
But I didn't get the point.
Do I want to write my own string comparison code and use that as Custom
Collation .If so where can I find the examples.(or) I can use just
sqlite3_create_function( *gpst_SqliteInstance, "shellstatic", 0,
SQLITE_UTF16, 0, shellstaticFunc, 0, 0); My database has UTF16 encoding.

Even if the collation is UTF8, Sqlite will do memcmp() say 1st record
has the Unicode 6B4C and 2nd records has 30A2.If sqlite is comparing
byte by byte means then 30A2 only has to come as first record.Is it
right? But I am not getting.

Please help to clarify this.

Thanks & Regards,
Mahalakshmi






___
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] Who is using SQLite prior to version 3.3.0?

[Rich Shepard]

On Mon, 12 May 2008, D. Richard Hipp wrote:

> Note that on older systems this should not be a problem since
> databases will be both created and read by older versions of SQLite.

> The only time this will cause a problem is when you create a new
> database file using SQLite 3.6.0 or later and then try to read or
> write that file using a different version of SQLite that is more than
> 2 years old.

Richard,

   Looking at these two conditions suggests that there will be no problems
created by making your suggested change.

   If older databases create and read files in the older format version, then
it does not matter what version is used for the newest files.

   The suggested change appears to have no impacts that cannot be easily
avoided.

Rich

-- 
Richard B. Shepard, Ph.D.   |  IntegrityCredibility
Applied Ecosystem Services, Inc.|Innovation
 Voice: 503-667-4517  Fax: 503-667-8863
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Who is using SQLite prior to version 3.3.0?

[D. Richard Hipp]

On May 12, 2008, at 12:00 PM, Scott Baker wrote:
>
> What's the advantage to making all new DBs created format 4? I'm  
> against
> breaking backwards compatibility.

Please reread the post carefully.  This is *not* a backwards  
compatibility break.  Format 4 provides DESC index capability and a  
tighter encoding for boolean values.  Every version of SQLite released  
over the past 2 years can read and write both format 4 and format 1  
without any problems.  However, if you create a new database in format  
4 and then try to read it using a version of SQLite that is more than  
2 years old, the older SQLite will be unable to read the file and will  
return an error.

Note that on older systems this should not be a problem since  
databases will be both created and read by older versions of SQLite.

Note that for upgrading this should not be a problem since older  
database will continue to be readable and writable by newer versions  
of SQLite.

The only time this will cause a problem is when you create a new  
database file using SQLite 3.6.0 or later and then try to read or  
write that file using a different version of SQLite that is more than  
2 years old.

D. Richard Hipp
[EMAIL PROTECTED]



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

Re: [sqlite] Who is using SQLite prior to version 3.3.0?

[Dan]

On May 12, 2008, at 11:00 PM, Scott Baker wrote:

> D. Richard Hipp wrote:
>> Is there anybody still using a version of SQLite prior to version
>> 3.3.0 in a context where they might want to read a database file that
>> was created by the latest version of SQLite?
>>
>> The reason I ask is this:  SQLite understands two slightly different
>> file formats, format 1 and format 4.  (Ok, it also understands  
>> formats
>> 2 and 3, but they don't come into play here so ignore that fact for
>> the moment.)  In format 4, SQLite uses a tighter encoding for boolean
>> values and it honors the DESC keyword on indices.
>>
>> All versions of SQLite since 3.3.0 can read and write both format 1
>> and format 4.  But versions of SQLite prior to 3.3.0 could only
>> understand format 1.  New database files are created in format 1 by
>> default in order to be readable and writable by older versions of
>> SQLite.  I'm wondering if we have reached a point where this can
>> change.  Can we move to creating new database files in format 4 by
>> default.
>>
>> Please note that this is not a backwards compatibility break.  All
>> prior database files will still be readable and writable by any
>> version of SQLite after 3.3.0.  But this is a forwards compatibility
>> break.  Database files created by SQLite version 3.6.0 or later will
>> likely be unreadable by SQLite version 3.2.8 and earlier.
>>
>> If we do move to creating new database files in format 4 by default,
>> an application will still be able to create format 1 database files
>> using a pragma.  Or, a compile-time option can be used to force  
>> format
>> 1 databases to be used as the default.
>>
>> FWIW, SQLite version 3.3.0 was released over 2 years ago on January
>> 10, 2006.
>
> What's the advantage to making all new DBs created format 4? I'm  
> against
> breaking backwards compatibility. One of the most annoying this about
> SQLite is that version 3.x can't open version 2.x databases (which
> unfortunately are still out there).

I think the short answer is that with version 4:

   * Descending indexes are properly supported, and
   * Integer values 0 and 1 consume a single byte of space in a database
 record. With format version 1 they consume 2 bytes.

Dan.


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

Re: [sqlite] Who is using SQLite prior to version 3.3.0?

[Scott Baker]

D. Richard Hipp wrote:
> Is there anybody still using a version of SQLite prior to version  
> 3.3.0 in a context where they might want to read a database file that  
> was created by the latest version of SQLite?
> 
> The reason I ask is this:  SQLite understands two slightly different  
> file formats, format 1 and format 4.  (Ok, it also understands formats  
> 2 and 3, but they don't come into play here so ignore that fact for  
> the moment.)  In format 4, SQLite uses a tighter encoding for boolean  
> values and it honors the DESC keyword on indices.
> 
> All versions of SQLite since 3.3.0 can read and write both format 1  
> and format 4.  But versions of SQLite prior to 3.3.0 could only  
> understand format 1.  New database files are created in format 1 by  
> default in order to be readable and writable by older versions of  
> SQLite.  I'm wondering if we have reached a point where this can  
> change.  Can we move to creating new database files in format 4 by  
> default.
> 
> Please note that this is not a backwards compatibility break.  All  
> prior database files will still be readable and writable by any  
> version of SQLite after 3.3.0.  But this is a forwards compatibility  
> break.  Database files created by SQLite version 3.6.0 or later will  
> likely be unreadable by SQLite version 3.2.8 and earlier.
> 
> If we do move to creating new database files in format 4 by default,  
> an application will still be able to create format 1 database files  
> using a pragma.  Or, a compile-time option can be used to force format  
> 1 databases to be used as the default.
> 
> FWIW, SQLite version 3.3.0 was released over 2 years ago on January  
> 10, 2006.

What's the advantage to making all new DBs created format 4? I'm against 
breaking backwards compatibility. One of the most annoying this about 
SQLite is that version 3.x can't open version 2.x databases (which 
unfortunately are still out there).

Now we're talking about breaking forwards compatibility... I dunno. I like 
the idea of keeping things as compatible as possible.


-- 
Scott Baker - Canby Telcom
RHCE - System Administrator - 503.266.8253
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Distributed transaction best practices

[Virgilio Alexandre Fornazin]

The best you can do actually with SQLite is a 'mirror-replicating' mode
engine
that works like Microsoft Windows Active Directory Database, to build a king
of 
High Availability / Load Balancing server.

You have a farm of servers (or workstations, etc) receiving SQL commands by
a 
channel (socket, pipe, whatever). They force a 'election' do decide what´s
the
best servers to become master, then they agree on that and transactions (all

commands that modify the database) are first applied to the master server
then
'mirrored' to slave servers. In this design, if a 'child' server cannot
complete
the transaction that are completed by master and any other server, there is
a
critical problem in that slave node, and you must consider it offline or
some kind of state that you need to check if by hand or by one tool you
might
develop for this. In this scenario, you can do a 'load balance' in SELECT´s,
distributing querying belong all servers, creating affinities for tables, 
buffering most used tables in a memory database, etc.

I´m currently implementing services for finantial stock exchanging services
that
works in the way I told you, if you are planning something that we can have
in the
way SQLite is (not tied to any kind of restrictive license), we can share
knowledge 
and implement a solution like that. (PS: I don't have full time to work on
it, but 
I can help in free hours)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Griggs, Donald
Sent: segunda-feira, 12 de maio de 2008 10:47
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Distributed transaction best practices

Hi David,


Regarding:  "What are the recommended "best practices" around using
SQLite in a distributed scenario?"  [two-phase commit, etc.]

I trust that someone with some actual relevant knowledge will reply to
your query later, but I imagine that many would say the the "recommend
best practice" is *not* to use sqlite, since sqlite was designed to be
an elegant embedded database -- without even one server -- let alone
multiple synchronized ones.

I take it you have strong reasons for rejecting, say, Postgres, which
now implements two-phase commmit right out of the box?  
 
http://www.postgresql.org/docs/current/static/sql-prepare-transaction.ht
ml

You may already know everything in articles such as this one
 
http://en.wikipedia.org/wiki/Two_phase_commit#Distributed_two-phase_comm
it_protocol
And its references (I don't claim to), but I'm listing it here just it
case it's helpful to you.

On the other hand, if you *do* develop a solid "distributed sqlite"
implementation, I'm sure others would be interested.

Regards,
  Donald Griggs

 


This email and any attachments have been scanned for known viruses using
multiple scanners. We believe that this email and any attachments are virus
free, however the recipient must take full responsibility for virus
checking. 
This email message is intended for the named recipient only. It may be
privileged and/or confidential. If you are not the named recipient of this
email please notify us immediately and do not copy it or use it for any
purpose, nor disclose its contents to any other person.
___
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

[sqlite] Is this Sorting order right?

[Mahalakshmi.m]

Mahalakshmi wrote 
> What about Japanese Kanji?
> Will sqlite sort all the Hiragana,Katakana,Kanji.

Igor Tandetnik wrote

>> Not out of the box. You will have to implement a custom collation. Or, 
>> you can build SQLite with ICU support, then it >> will use ICU collation
>> functions.

Thanks a lot.
But I didn't get the point.
Do I want to write my own string comparison code and use that as Custom
Collation .If so where can I find the examples.(or) 
I can use just sqlite3_create_function( *gpst_SqliteInstance, "shellstatic",
0, SQLITE_UTF16, 0, shellstaticFunc, 0, 0); My database has UTF16 encoding.

Even if the collation is UTF8, Sqlite will do memcmp() say 1st record has
the Unicode 6B4C and 2nd records has 30A2.If sqlite is comparing byte by
byte means then 30A2 only has to come as first record.Is it right? But I am
not getting.

Please help to clarify this.

Thanks & Regards,
Mahalakshmi






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

[sqlite] Who is using SQLite prior to version 3.3.0?

[D. Richard Hipp]

Is there anybody still using a version of SQLite prior to version  
3.3.0 in a context where they might want to read a database file that  
was created by the latest version of SQLite?

The reason I ask is this:  SQLite understands two slightly different  
file formats, format 1 and format 4.  (Ok, it also understands formats  
2 and 3, but they don't come into play here so ignore that fact for  
the moment.)  In format 4, SQLite uses a tighter encoding for boolean  
values and it honors the DESC keyword on indices.

All versions of SQLite since 3.3.0 can read and write both format 1  
and format 4.  But versions of SQLite prior to 3.3.0 could only  
understand format 1.  New database files are created in format 1 by  
default in order to be readable and writable by older versions of  
SQLite.  I'm wondering if we have reached a point where this can  
change.  Can we move to creating new database files in format 4 by  
default.

Please note that this is not a backwards compatibility break.  All  
prior database files will still be readable and writable by any  
version of SQLite after 3.3.0.  But this is a forwards compatibility  
break.  Database files created by SQLite version 3.6.0 or later will  
likely be unreadable by SQLite version 3.2.8 and earlier.

If we do move to creating new database files in format 4 by default,  
an application will still be able to create format 1 database files  
using a pragma.  Or, a compile-time option can be used to force format  
1 databases to be used as the default.

FWIW, SQLite version 3.3.0 was released over 2 years ago on January  
10, 2006.

D. Richard Hipp
[EMAIL PROTECTED]



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

Re: [sqlite] Distributed transaction best practices

[Griggs, Donald]

Hi David,


Regarding:  "What are the recommended "best practices" around using
SQLite in a distributed scenario?"  [two-phase commit, etc.]

I trust that someone with some actual relevant knowledge will reply to
your query later, but I imagine that many would say the the "recommend
best practice" is *not* to use sqlite, since sqlite was designed to be
an elegant embedded database -- without even one server -- let alone
multiple synchronized ones.

I take it you have strong reasons for rejecting, say, Postgres, which
now implements two-phase commmit right out of the box?  
 
http://www.postgresql.org/docs/current/static/sql-prepare-transaction.ht
ml

You may already know everything in articles such as this one
 
http://en.wikipedia.org/wiki/Two_phase_commit#Distributed_two-phase_comm
it_protocol
And its references (I don't claim to), but I'm listing it here just it
case it's helpful to you.

On the other hand, if you *do* develop a solid "distributed sqlite"
implementation, I'm sure others would be interested.

Regards,
  Donald Griggs

 


This email and any attachments have been scanned for known viruses using 
multiple scanners. We believe that this email and any attachments are virus 
free, however the recipient must take full responsibility for virus checking. 
This email message is intended for the named recipient only. It may be 
privileged and/or confidential. If you are not the named recipient of this 
email please notify us immediately and do not copy it or use it for any 
purpose, nor disclose its contents to any other person.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users