Yes, it is only a remote possibility. However, my understanding is that this is the very reason that "tmpnam" has been declared "dangerous" - there's no guarantee that between the time you get the file name and actually create the file and open it, some other process hasn't snuck in and already created it. gcc warns about its use and mkstemp is recommended instead because it creates and opens the file "atomically". But that doesn't help because SQLite can't use the file created by msktemp. Since using tmpnam is considered bad practice, I was hoping to find some other solution that doesn't suffer from this same race condition, and as stated it does not seem possible. Anyway, thanks for your replies. I think it would be wise for SQLite to provide some foolproof solution to this in the future - if "tmpnam" is dangerous due to the race condition it creates, I would think SQLite would also be interested in helping developers avoid the same kind of problem when it comes to temporary databases. Providing the name of a temp database created by SQLite would solve the problem, but there may be other ways too. For example, AFAIK, the only way to accomplish the ATTACH DATABASE capability is to use that statement with the name of the database file to attach, but perhaps an API could be created which allows the equivalent thing, but using the database connection handle instead of the file name. Just thinking out loud.