I recently faced the problem that Btrieve (or Pervasive SQL) cannot create (and handle) long filename (non 8+3) on NetWare volumes mounted after Btrieve loaded.
It needed some time to find out and verify that this is the real cause, and also working out a fix that Btrieve would be loaded after all volume mounted.
Putting bstart at the very beginnig of the autoexec.ncf (after server name and internal ipx) could work for cases where the server is “old”, eg. 3.12 or 4.11-non Small Business, however, on a Small Business and from 5.x, after mounting sys, DS autoloads, which autoloads NLS (Licensing Services), which autoloads Btrieve. Other volume mounts likely to finish after these happened. TCPIP.NLM also relies on Btrieve so as ArcServe for example.
After a little while, I realized that the simplest solution is just put a bstop and a bstart into autoexec.ncf - somewhere after volumes are all mounted - optionally with some delay, such as:
mount all
?# - this will wait for 10 seconds (unless default overridden)
?# - another 10 seconds
bstop.ncf
bstart.ncf
Btrieve will not unload completely, but the essential files will, then after a bstart, all mounted volumes will be recognized and used by Btrieve as “long-filename capable” (given that OS2 or LONG name space added of course).