Re: [sqlite] From Windows file format to MacOSX (unsuccessfull)
Well, it didn't seem to work when I copied the file to MacOSX. It said (after accepting to go into command line mode) "invalid file format". I don't have an intel box to test now, so I will try again on monday at the office. My other option is to save the data in 2.8 format and convert from 2.8 to 3.1 with the dump command as explained in the documentation. I installed the 2.8 version from darwinports on MacOSX. Obviously, I would rather have the first solution working. Thanks, Alex -- Alexander Lamb [EMAIL PROTECTED] On Aug 4, 2006, at 6:11 PM, [EMAIL PROTECTED] wrote: Alexander Lamb <[EMAIL PROTECTED]> wrote: Well, I am afraid it didn't work. Somehow, the legacy_file_format info is not "sticky". The "legacy_file_format" pragma does not appear to be sticky, but it is. The value reported back by PRAGMA legacy_file_format is incorrect. But the legacy file format did get set. Mario Frasca <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: Adding DATE and TIMEINTERVAL types to SQLite would require an incompatible file format change. well, yes, that was already clear. but: where is the type of the data being stored? aren't there a few spare bits to use for 'future additions', that is, new data types? sure, a file containing date data would not be understood by executables where this has not been defined, but maybe it is possible to do it so that they see a 'text'... or maybe not... Mario: Look back over this thread, and others before it, and observe all the grief that gets caused by file format changes. I've learned my lesson: No more file format changes except too fix a serious bug. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] From Windows file format to MacOSX (unsuccessfull)
Alexander Lamb <[EMAIL PROTECTED]> wrote: > Well, I am afraid it didn't work. > > Somehow, the legacy_file_format info is not "sticky". > The "legacy_file_format" pragma does not appear to be sticky, but it is. The value reported back by PRAGMA legacy_file_format is incorrect. But the legacy file format did get set. Mario Frasca <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > >Adding DATE and TIMEINTERVAL types to SQLite would require an > >incompatible file format change. > > > well, yes, that was already clear. but: where is the type of the data > being stored? aren't there a few spare bits to use for 'future > additions', that is, new data types? sure, a file containing date data > would not be understood by executables where this has not been defined, > but maybe it is possible to do it so that they see a 'text'... or maybe > not... > Mario: Look back over this thread, and others before it, and observe all the grief that gets caused by file format changes. I've learned my lesson: No more file format changes except too fix a serious bug. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] From Windows file format to MacOSX (unsuccessfull, still)
Alexander Lamb wrote: Well, I even tried to insert a row in the table. The table contains the data. The file on the disk is 2K length. The PRAGMA commands tells me I am in legacy file format mode (1) but when I quit then return, I am back to 0! I just tried the same thing and got the same result. It is possible that the only problem is that the pragma is not returning the expected result, but is in fact changing the file format when used as directed. Have you tried copying the file to your Mac to see whether it can be read? Gerry, admittedly grasping at straws
Re: [sqlite] From Windows file format to MacOSX (unsuccessfull, still)
Alexander Lamb uttered: Well, sorry, but I did exactly that: 1) When I do the PRAGMA command the file is created (I can see it appearing in the explorer) 2) After the create table, if I do PRAGMA legacy_file_format; I indeed receive "1" as an answer. However, I ".quit" then go back into the database and ask PRAGMA legacy_file_format; it returns "0". Once I quit, it "reverts" to 0?? The problem is that the file created is zero length until actual data (or meta-data) is inserted. Thus, you need to at least create a table. Then, once some data has been created, the header will contain the correct legacy_file_format information. Well, I even tried to insert a row in the table. The table contains the data. The file on the disk is 2K length. The PRAGMA commands tells me I am in legacy file format mode (1) but when I quit then return, I am back to 0! Could it be a wrong version of SQLite? When I ask for the version I get 3.3.6 I simply installed the .exe and .dll from the Windows package I found on the web site. Alex
Re: [sqlite] From Windows file format to MacOSX (unsuccessfull, still)
Alexander Lamb uttered: Well, sorry, but I did exactly that: 1) When I do the PRAGMA command the file is created (I can see it appearing in the explorer) 2) After the create table, if I do PRAGMA legacy_file_format; I indeed receive "1" as an answer. However, I ".quit" then go back into the database and ask PRAGMA legacy_file_format; it returns "0". Once I quit, it "reverts" to 0?? The problem is that the file created is zero length until actual data (or meta-data) is inserted. Thus, you need to at least create a table. Then, once some data has been created, the header will contain the correct legacy_file_format information. So, if I have to issue a PRAGMA legacy_file_format=ON; each time I enter sqlite, I have a problem when I access the database through ODBC. I have no way to issue that PRAGMA command! Am I correct in my reasonning? -- Alexander Lamb [EMAIL PROTECTED] On Aug 4, 2006, at 4:31 PM, [EMAIL PROTECTED] wrote: Alexander Lamb <[EMAIL PROTECTED]> writes: 1. (*) text/plain Well, I am afraid it didn't work. Somehow, the legacy_file_format info is not "sticky". I did: sqlite3 then in command mode: PRAGMA legacy_file_format=ON; then ATTACH "d:\mydb.db" AS mydb; In order to have done an ATTACH, the database had to have already existed. That's too late. Instead, ensure that mydb.db *does not exist*, and then do: sqlite3 d:\mydb.db PRAGMA legacy_file_format=ON; CREATE TABLE TEST (id INTEGER); The next time you then access the file, it will have the proper format. Derrell -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
Re: [sqlite] From Windows file format to MacOSX (unsuccessfull, still)
Well, sorry, but I did exactly that: 1) When I do the PRAGMA command the file is created (I can see it appearing in the explorer) 2) After the create table, if I do PRAGMA legacy_file_format; I indeed receive "1" as an answer. However, I ".quit" then go back into the database and ask PRAGMA legacy_file_format; it returns "0". Once I quit, it "reverts" to 0?? So, if I have to issue a PRAGMA legacy_file_format=ON; each time I enter sqlite, I have a problem when I access the database through ODBC. I have no way to issue that PRAGMA command! Am I correct in my reasonning? -- Alexander Lamb [EMAIL PROTECTED] On Aug 4, 2006, at 4:31 PM, [EMAIL PROTECTED] wrote: Alexander Lamb <[EMAIL PROTECTED]> writes: 1. (*) text/plain Well, I am afraid it didn't work. Somehow, the legacy_file_format info is not "sticky". I did: sqlite3 then in command mode: PRAGMA legacy_file_format=ON; then ATTACH "d:\mydb.db" AS mydb; In order to have done an ATTACH, the database had to have already existed. That's too late. Instead, ensure that mydb.db *does not exist*, and then do: sqlite3 d:\mydb.db PRAGMA legacy_file_format=ON; CREATE TABLE TEST (id INTEGER); The next time you then access the file, it will have the proper format. Derrell
Re: [sqlite] From Windows file format to MacOSX (unsuccessfull)
Alexander Lamb <[EMAIL PROTECTED]> writes: > 1. (*) text/plain > > Well, I am afraid it didn't work. > > Somehow, the legacy_file_format info is not "sticky". > > I did: > > sqlite3 > > then in command mode: > > PRAGMA legacy_file_format=ON; > > then > > ATTACH "d:\mydb.db" AS mydb; In order to have done an ATTACH, the database had to have already existed. That's too late. Instead, ensure that mydb.db *does not exist*, and then do: sqlite3 d:\mydb.db PRAGMA legacy_file_format=ON; CREATE TABLE TEST (id INTEGER); The next time you then access the file, it will have the proper format. Derrell
Re: [sqlite] From Windows file format to MacOSX (unsuccessfull)
Well, I am afraid it didn't work. Somehow, the legacy_file_format info is not "sticky". I did: sqlite3 then in command mode: PRAGMA legacy_file_format=ON; then ATTACH "d:\mydb.db" AS mydb; then CREATE TABLE TEST (id int); if I then quit and return to sqlite3 and attach the database I just created and issue the following command: PRAGMA legacy_file_format; I get the answer "0" (when it was "1" during the previous session). This means that when I export my tables from Access to the ODBC datasource of SQLite3, it does not keep the fact it has to write "legacy format". This confirmed by the fact I can't read the database on my Mac. Did I do something wrong? Thanks, Alex -- Alexander Lamb [EMAIL PROTECTED] On Aug 4, 2006, at 3:34 PM, Alexander Lamb wrote: Ahah, I understood "PRAGMA" as an compile option :-( That's why point 2 was not very clear (I am new to SQLite). I'll do this right away! Thanks, Alex -- Alexander Lamb [EMAIL PROTECTED] On Aug 4, 2006, at 3:27 PM, Gerry Snyder wrote: Alexander Lamb wrote: So it is not possible to create a database with the legacy file format using the command line on Windows and SQLite 3.3? Yes it is. Reread Dr. Hipp's point (2) below. If I understand correctly, I need to grab the latest CVS version of SQLite to have the 3.3 format disabled by default. Yes, but you do not need to use the default. You just need to issue the pragma command before creating the first table in the new file. Reread Dr. Hipp's point (2) below. The problem I see with that is that I am not a Windows developer so I have no way of compiling the .exe and .dll No need. That was just one of the suggestions. On Aug 4, 2006, at 12:13 PM, [EMAIL PROTECTED] wrote: Either (1) use the latest version of SQLite from CVS or (2) run PRAGMA legacy_file_format=ON; prior to creating that first table in the SQLite database. Hope this helps. Sorry I was too lazy to correct the top-posting. The mish=mash may be hard to read. Gerry
