I don't know. The standard debug doesn't print the name, so I will have to add something tomorrow.
I can tell you the name of the database file is /ata0:3/testdb.sql and it gets created. It is possible things are working. It is just that the sqlite3_exec is not returning SQLITE_OK, so I give up and print an error. I wonder if before the check was added to unixDelete all unlink errors were ignored. So it would have worked just fine and you wouldn't have known it was trying to delete files that didn't exist. I will investigate further tomorrow and let you know the file names. Regards Andy Ling ________________________________ From: drhsql...@gmail.com [drhsql...@gmail.com] on behalf of Richard Hipp [d...@sqlite.org] Sent: 12 August 2014 19:15 To: Andy Ling Cc: General Discussion of SQLite Database; 王庆刚 Subject: Re: [sqlite] HELP sqlite3 used in vxworks has someproblem？ What is the name of the file that SQLite is trying to delete but which does not exist? And what is the name of the corresponding database file? The name of the file that fails unlink() will give us a big clue about what is going wrong. On Tue, Aug 12, 2014 at 2:13 PM, Richard Hipp <d...@sqlite.org<mailto:d...@sqlite.org>> wrote: On Tue, Aug 12, 2014 at 2:00 PM, Andy Ling <andy.l...@quantel.com<mailto:andy.l...@quantel.com>> wrote: Because the file doesn't exist. I assume because this is a brand new database the file hasn't been created yet. I did debug this originally, but I don't remember the file it is trying to delete. It definitely didn't exist though. To some extent it doesn't really matter. The unixDelete function on vxWorks with dosFs is broken for files that don't exist, so some change is needed. That check to ignore the error when trying to delete a file that does not exist - that check was only added less than 2 years ago, 2012-11-10. So for the first 8 years of its history, billions of instances of SQLite3 got along fine without that check. This is not surprising since an attempt to delete a file that does not exist should only come up in very rare circumstances. So we can update the unixDelete routine for that. But, the fact that your build of SQLite does not work *at all* without such a change suggests that there are other problems - problems that are being masked, but not resolved, by the unixDelete change. I'm trying figure out what those other problems are. -- D. Richard Hipp d...@sqlite.org<mailto:d...@sqlite.org> -- D. Richard Hipp d...@sqlite.org<mailto:d...@sqlite.org> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
