Results 1 to 7 of 7
  1. #1
    Join Date
    Jul 2008
    Posts
    3

    Question Unanswered: BDE in ASP .NET or Microsoft SQL

    A huge portion of our company's data is managed in Paradox tables and traditionally we have been using Corel Paradox 8 to access these tables.

    I have been exploring accessing and manipulating these tables in ASP .Net so that we can move all our users to a web interface eventually.

    I've experimented with using Intersolv's ODBC drivers that come with Paradox 10 as well as the newer ones in trial from DataDirect. The newer drivers work just as well as the older drivers in my opinion. The version of BDE that I have been using is BDE 5.0.

    I am aiming at deploying the bulk of website on Windows 2000 however we do have Windows 2003 servers available. The actual paradox database is hosted in a Windows 2000 machine with all the Windows 2000 updates as far I know.

    The combination of software (in particular .Net and BDE) seem to perform very differently on Windows 2003 compared to on Windows 2000.

    The main quirk is when the driver's first load I receive a "Network Initialization Failed" error. This continues until I access the page locally on the server, At which point the driver works consistently. I'm guessing my ODBC settings are somewhat correct (I am using UNC paths to access the PDOXNET.NET file). Another thing to note is that the drivers and BDE seem to work just fine when run from a desktop. In other words if I used a VBScript or launched an application that used the drivers things are fine.

    I also gotten these drivers to run via a Linked Server but support for transactions is limited. I had to do some creative coding in .Net to get around this.

    It just seems that most of these problems stem from the fact that paradox is a flat file database and BDE has to be able to do a lot of file operations over a network in a desktopless environment.

    Any help would be appreciated.

  2. #2
    Join Date
    Dec 2007
    Posts
    366
    either your understanding of paradox tables is limited, or what you've been given to work with is VERY poorly designed..

    but support for transactions is limited

    paradox tables do not support transactions, and never have..




    most of these problems stem from the fact that paradox is a flat file database

    totally incorrect.. if the app and tables that you're using are flat-file in nature, it's because the designers of the system had no clue about relational theory (or ignored "good practice" for some reason)..


    seem to perform very differently on Windows 2003 compared to on Windows 2000

    if everything is loaded, mapped, and deployed the same way, there will be no difference..

    also, as you move thru this, you should be giving strong consideration to moving out of the current platform.. all Paradox and BDE development and support stopped about 8 years ago.. the remaining developer community is shrinking by the day..
    --
    Steven Green - Myrtle Beach, South Carolina USA

    http://www.OasisTradingPost.com

    Oasis Trading Post
    - Collectibles and Memorabilia
    - Vintage Lego Sets and Supplies
    - and Paradox Support, too

  3. #3
    Join Date
    Jul 2008
    Posts
    3
    On the first point I agree paradox tables by themselves do not support transactions. Whatever illusion of a transaction is handled in either BDE or the ODBC drivers. What is important here is when I call BeginTrans, RollBackTrans, and CommitTrans on a ADODB.Connection object I get the desired effect.

    I'm not going to really argue against the point that if everything is setup in the same manner across two Operating Systems things should work the same.

    Flat-file was a very poor choice of words.

    There really is not much point in arguing on design of our system. It is what it is. I did not build it.

    On the last point, moving data out of paradox is really my ultimate goal for the reasons you have provided.

    This is not something that we can just do all at once. The company has used this software for over a decade and I think things are reaching their limits.

    There have been several considerations on how best to go about this process. Moving tables over one by one to our SQL Server is one consideration. The problem is there is a lot of ObjectPal that we have to fix in Paradox for business to keep moving while we do this.

    The other consideration was to build everything we need all at once and then move all our data over at once. Management is not a big fan of this solution. Another issue that makes this difficult is poor data integrity which will not go over well when we move everything into SQL.

    My final solution and the one that I'm going with is to try to build all our utilities outside of Paradox and then start phasing out the tables.

    But what I need to figure out is what changes need to be made in Windows, BDE, IIS, etc to make this possible. Otherwise we're just going to continue using software that is over a decade old.
    Last edited by bmouton; 07-22-08 at 15:09.

  4. #4
    Join Date
    Dec 2007
    Posts
    366
    sorry if I'm a bit blunt, but this scenario is exactly why I have to make the points I'm making.. you're asking how to force an old paradox app to run properly in an environment where it CAN'T run properly.. and I know it's not your fault..

    I'm not going to really argue against the point that if everything is setup in the same manner across two Operating Systems things should work the same.

    agreed.. my point here, is to use the "good" one to check the "bad" one.. mapping, access rights, BDE settings, oplocks and write-behind settings, etc..

    This is not something that we can just do all at once.

    most experiences indicate that all-at-once, with parellel testing, is the best course of action.. mixing platforms along the way can get VERY complex..

    The problem is there is a lot of ObjectPal that we have to fix in Paradox for business to keep moving while we do this.
    --
    Steven Green - Myrtle Beach, South Carolina USA

    http://www.OasisTradingPost.com

    Oasis Trading Post
    - Collectibles and Memorabilia
    - Vintage Lego Sets and Supplies
    - and Paradox Support, too

  5. #5
    Join Date
    Dec 2007
    Posts
    366
    sorry, pushed the wrong button..

    The problem is there is a lot of ObjectPal that we have to fix in Paradox for business to keep moving while we do this.

    in all liklihood, you'll have to completely revamp the paradox app to use sql tables, and I'm sure you know that.. the level of changes, the testing, etc., are often insane.. that's why "all at once" is better.. but do the powers-that-be understand this?
    --
    Steven Green - Myrtle Beach, South Carolina USA

    http://www.OasisTradingPost.com

    Oasis Trading Post
    - Collectibles and Memorabilia
    - Vintage Lego Sets and Supplies
    - and Paradox Support, too

  6. #6
    Join Date
    Jul 2008
    Posts
    3
    The powers-that-be understands this and may not be willing to devote too much time and man power to a single project.

  7. #7
    Join Date
    Dec 2007
    Posts
    366
    you'll have a ton of questions over time, so you should start posting on the community newsgroup instead, where there is much more help than just me..

    www.thedbcommunity.com

    that's where most of the remaining paradox community hangs out..
    --
    Steven Green - Myrtle Beach, South Carolina USA

    http://www.OasisTradingPost.com

    Oasis Trading Post
    - Collectibles and Memorabilia
    - Vintage Lego Sets and Supplies
    - and Paradox Support, too

Posting Permissions

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