Just to expand on the problem of the open command that I outlined earlier, I tested under a compiled version of sqlite (3.06) in the terminal application and passed the following:

[jbedwards:4DSqlite3/sqlite/bin] jeffedwa% ./sqlite3 HD/Applications/jeff.db
SQLite version 3.0.6
Enter ".help" for instructions
sqlite> create table TEST(name varchar(30))
...> go
Unable to open database "HD/Applications/jeff.db": unable to open database file
[jbedwards:4DSqlite3/sqlite/bin] jeffedwa% ./sqlite3 HD:Applications:jeff.db
SQLite version 3.0.6
Enter ".help" for instructions
sqlite> create table TEST(name varchar(30))
...> go
sqlite> .quit
[jbedwards:4DSqlite3/sqlite/bin] jeffedwa%


The file that was created was located in the bin directory and named "HD/Applications/jeff.db"
In other words the file name has forward slashes in it which were replaced from the colans.
If I have forward slashes in the path to the file I am wishing to create, then I get an error.
Something is definitely wrong with this part of the program



I also have another problem stemming from version 3. The open command seems not to work with the API. In other words, if the OS is macosx and I pass colans as the path delimiter, I end up getting a file name with slashes. if I pass a path name with forward slashes as the delimiter then I get an error. . . and sometimes I get no error returned, but still no file is created. So it seems that the new way of opening (and creating where the file is not created immediately) has broken something. Any ideas?

Best regards,


Jeff Edwards



Reply via email to