Jeff Edwards wrote: > I wrote about this problem previously. > > There is a type definition in Sqlite named "Cursor" that is in conflict with > a Quick Time data type in Code Warrior. Now that I am using XCode to compile > my 4D plugin, it appears that the same conflict exists. . . so it is not only > defined in the Carbon headers of CW but also XCode. Would you consider > changing the name to something like "Sqlite_Cursor".
No.
The "Cursor" object in SQLite is an internal name. It does not appear anywhere in "sqlite.h" or "sqlite3.h". Since the neither XCode nor Carbon are required to compile SQLite, the definition of Cursor should not appear in any of the files included by SQLite either. So there should be no conflicts. If you are getting conflicts, I think the blame belongs to the build environment, not SQLite. I think it ill-advised to go around altering names in SQLite in order to work around problems in obscure build environments such as Code Warrior for Mac OS 9.
> I need to go through the sources for every update and search and replace > before I can get a successful compile.
Or, you could use a single #define to accomplish the same thing....
> 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 mac 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? >
SQLite version 3.0 does not work with Mac OS-9 since nobody has ever submitted drivers for it. There is a file named "os_mac.c" in the distribution, but it busted. If you want to use OS-9 you'll need to stick with SQLite version 2.8.
-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
