Since 2000i is not supported on SBS 2003, I decided that rather than take chances I would get v10 for my new server. However, I was not able to get DBA/Evo to work. The connectivity tests passed, but I kept getting error 116 messages (another gateway has the files, or something like that).
 
I ended up removing v10 and installing 2000i, and voila! It works.
 
So, my question is, is there anything special I need to do with v10? With 2000i all I did was install the server on the server and the client on the workstations. No configuration, settings or anything. With v10 I installed the workgroup engine on both the server and the workstations, although from what the instructions said it sounded like I wouldn't actually need it on the server unless I was actually running the application on the server.
 
OTOH, if it works...

Well, some day when I have nothing else to do (ROTFLMHO), maybe I'll give that a try.
 
I do have a question about how the workgroup version works though. It seems to me like I should have the workgroup engine installed on the server and the server set as the gateway. Wouldn't that minimize the network traffic rather than a workstation handling all the requests for the server just because it (the workstation) happened to make the first request?
 
(I don't have and real idea how Pervasive works, and a little knowledge is a dangerous thing....)

Here's a bit of information that hopefully fills in the blanks:
 
The Workgroup Engine (WGE) and the Client/Server Engine (CSE) are very similar, and they share a common code base.  The major differences are in the area of security (the CSE checks for user rights, while the WGE does NO security checking), performance (the CSE uses asynchronous I/O while the WGE does not) and a few additional features (Backup Agent, 64-bit support, and XtremeIO drivers all require a server engine).  They also differ in terms of licensing -- the WGE is licensed PER INSTALLED COMPUTER, meaning that you need one license for EACH ocmputer on which it is installed, and it can allow sharing of files from up to 5 concurrent machines at most.  The CSE is licensed PER SERVER, and limits you to the number of concurrent users as per the license count.  Thus, you can install a 6-User Server engine onto a server, put the client on 100 computers, and you'll have access to the server database from any 6 computers at a time.
 
If you are hosting the files on a Windows box, then the WGE SHOULD be installed on the server as well (requiring an additional license).  This will provide the best stability and performance, as the data files are local to the engine that will be accessing them.  When you do this, you should also "lock down" the gateway -- i.e. use the Gateway Locator tool to specify that the database directory should be controlled by the server computer only.  This forces the server to be running the WGE, but ensures that you'll avoid communications problems and Status 116's from a workstation trying to take over.  (To make sure that the WGE is always started, load it as a service, which is an option at install time for PSQLv10, but which must be done manually for PSQLv9 or earlier.)
 
How does the WGE actually work?  When you ask your local WGE for access to a file, the system examines the data directory for a gateway file, called ~PVSW~.LOC.  If it does NOT find one, it creates one and stamps his computer name into the file, and that computer then becomes the gateway (i.e. production database engine) for that directory.  If it does find a gateway file, then the file is read to determine the computer name who is the gateway.  (If you see one of these files, you can also TYPE it to the screen to see who the gateway is, in addition to using the Gateway locator to view its contents.)  Now that we know who the gateway is, we then contact that gateway and we then make client/server calls to that computer, pretending that it is a server.
 
So, where does the 116 come from?  If we find a gateway file, we read the computer name from it, so we must try to contact the computer.  If the computer doesn't respond via Client/Server calls (i.e. it is shutting down, the engine abnormally ended, there's a network communications problem, we can't resolve the computer name to an address, there's a firewall blocking communications, an AntiVirus application is locking them open, etc.), then the WGE assumes that the gatewy file is old and it tries to take over, opening the files.  However, the files may still be in use by that other computer (especially if we have a networking or firewall problem), and the engine is unable to obtain the lock on the file and set itself as the gateway -- so it returns 116.
 
To prevent this, you have several options:
1) Your best option is to lock down the gateway to the server as the first option.  
2) Make sure that ALL computers can PING *ALL* other computers by NAME (not just by address).  In short, if the computer name is "MY_PC", then "MY_PC" will get stamped into the ~PVSW~.LOC file, and ALL other workstations will need to be able to PING MY_PC correctly.  
3) Make sure that internal PC firewalls are either disabled or allowing all communications from other machines, especially for ports 3351 and 1583 (the Pervasive ports), but also for NetBIOS ports (137/139) for the Named Pipe calls.
4) Make sure that all users map to the same share -- don't allow some users to map to different locations in the path and expect it to work.  All users should map to the same root location when they access files.
5) Switch to a CSE, which prevents 116's by not using WGE's to begin with.  If the server engine is unreachable, you simply don't work.
 
 
BTW, I am interested in getting DBA Classic running on PSQLv10 for my customers.  Has anyone been successful?  Does anyone have a testbed environment that we can play with, preferably as a Virtual Machine (VMWare or Microsoft)?

The biggest thing about PSQLv10 is that they have discontinued support for NetWare, client operating systems older than Windows 2000 (including Win98/95/ME), and support for 16-bit applications.  
 
What I haven't been able to find out is this -- are there any 16-bit Windows modules (that access the database) in DBA Classic?  Win32 and DOS apps are still supported with no problems, but we just need to know if there are any Win16 modules.  If not, then PSQLv10 should be just fine!

Wonderful. Thanks for the feedback!