New Palm OS Knowledge Base article today: FileOpen can't find file stream database on Palm OS Cobalt
A little background: while the common belief is that Palm OS can't handle files very well, the truth is that ever since Palm OS 3.0, there's been a File Stream API that lets you make in-memory databases that had file semantics. These were originally used by the Exchange Manager as a temporary store used during beaming to store the object being sent or received, but they can be used by any application. One reason why these aren't as popular has been that the file stream DBs are not backed up by default, and there is no bundled desktop tool to convert files to the stream format.
A file stream DB is just a normal Palm OS database with a file stream flag set in its header. The data is stored in 4K chunks, and the various routines let you read and write from this DB as if it were a flat file.
par, a command-line utility that I've praised in the past, will let you make file stream DBs on the desktop from any file. These can be synced to the device using the standard HotSync mechanism. One example of a program that uses this is ToySoft's LightWav, which wraps par in a GUI to let you put sound files on your device for use as alarms. I've also recently seen file streams used to store JPEG files with the Palm Photos application on the PalmOne Zire 71.
Anyway, I was helping some internal PalmSource people get a long text file into device memory, and suggested using par and the file stream APIs. The next day, I hear back from them about FileOpen always failing, so we pull in one of the Cobalt engineers, and we find out that on the new OS, file streams are implemented as extended databases. These are the new Cobalt versions of standard Palm OS DBs, but with a creator ID constrained namespace and the ability to have greater than 64K records.
This change made the standard FileOpen fail, since on Cobalt, it was looking for a extended DB. Fortunately, Cobalt also has a FileOpenV50 call that implements the old semantics and searches classic DBs, and double-fortunately, once you've opened the DB, all the other file stream APIs handle it correctly. Actually, there are both FileDelete and FileDelete50 calls too, but those don't work on open DBs, so I didn't mention them in my KB article.