Results 1 to 5 of 5
  1. #1
    Join Date
    Aug 2004
    Posts
    51

    Unanswered: Proper Development Setup

    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

  2. #2
    Join Date
    Dec 2001
    Posts
    1,109
    Provided Answers: 4
    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.
    Mirtheil Software
    Certified Pervasive Developer
    Certified Pervasive Technician
    Custom Btrieve/VB development
    http://www.mirtheil.com
    I do not answer questions by email. Please post on the forum.

  3. #3
    Join Date
    Aug 2004
    Posts
    51

    I'm starting to get it

    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

  4. #4
    Join Date
    Dec 2001
    Posts
    1,109
    Provided Answers: 4
    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.
    Mirtheil Software
    Certified Pervasive Developer
    Certified Pervasive Technician
    Custom Btrieve/VB development
    http://www.mirtheil.com
    I do not answer questions by email. Please post on the forum.

  5. #5
    Join Date
    Aug 2004
    Posts
    51

    Very helpful

    Thanks,

    That explains a lot.

    Kimball

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •