Mr. Mirtheil told me in another thread that the Pervasive engine doesn't send every communication back to the data manager in all cases. That could be the cause of some of the confusing things I'm experiencing trying to quickly get some stuff done with these tools.

So how should you set up a development environment when you want to prepare for a client/server deployment?

As I see it, there are six items:

1. The data folder with the btrieve and the ddf's.
2. the Pervasive 'engine'.
3. a dsn on the machine where the engine is.
4. a dsn on the machine where the dev tools are.
5. the data manager query tool.
6. the control center.

Now the connection for the data manager seems to already know something about the database selected in the control center. At least I've never had to manually set the connection if I open the data manager from the control center when the control center is showing stuff from the engine.

I pretty much ignore the client node of the control center. It seems to be for situations where the btrieve files are on the local machine.

But if you do a Print statement in the data manager while connected to the engine on a different machine, and the print occurs on the server, not in the data manager, that means that the engine pretty much only knows about the resources that are local to it. That is, its a one way connection from the data manager except for records returned.

So is it better to have the engine local on a dev machine and have it connecting to a data folder on a remote machine? Or what?

THanks,

Kimball

If you are going to use PRINT statements in Stored Procedures, then you should be prepared to run them local (unless your server is visible from your development machine). Pervasive always returns data to the calling application. Interactive functions like "PRINT" are handled at the engine level. Here's how I'm set up:
1. Development machine with local copy of the data, dev environments (C#, VB.NET, VB6, C), and local engine (server engine usually because it runs a service and it's works the same as the workgroup). Typically WInXP Pro.
2. Server (running Win2000/2003/Linux) running the Server engine with a copy of the data from the local machines. I create the same Engine DSNs as the dev machine.
3. CLient DSNs (with "cli" prefixing the Engine DSN name) on the Dev machine. Also have mapped drives for the Btrieve side of things.
I've also used Virutal PC but found it's almost as easy to reinstall an OS on one of my "server" machines.

Ok,

So the dsn's are really what the control center displays as nodes.

With a local server engine and local data, then it's like you're on the server.

Then with client dsn's pointing at the remote server engine, you can also see what's going to happen when you deploy.

So then what's a client 'engine'?

Thanks,

Kimball

Yes, DSNs are displayed.
The Client Engine can either be a Workgroup engine or the client requesters. The client requesters (with V8) include a Cache Engine which cannot access local data. Only a Workgroup or Server Engine can access local files.

Thanks,

That explains a lot.

Kimball