Results 1 to 13 of 13
  1. #1
    Join Date
    May 2004
    Posts
    4

    Angry Unanswered: MS SQL conflicting with other DB Engines.

    Hello All,
    I work for a company that packages MSDE and MSSQL 8.0 because our software requires storing client information in a database. The problem is that we've found that if the our users have another DB engine installed (BDE or Paradox usually), our program has trouble using MSDE to access the database and thus making our software inaccessible. It behaves as if this other database engine locks on our database before MSDE can. I'm basically looking for help on either how to uninstall these other db engines or how to get around this problem so that both MSSQL and other db engines can co-exist in one system.

  2. #2
    Join Date
    Apr 2003
    Location
    Washington DC area
    Posts
    1,770

    Cool MS SQL conflicting with other DB Engines

    I'd try to dump the data out of the other database to some type of file then import it in to sql server. Just a thought

  3. #3
    Join Date
    May 2004
    Posts
    4
    Thanks for the idea garrydawkins but unfortunately that's not an option we have.

  4. #4
    Join Date
    Jul 2003
    Location
    SoCal
    Posts
    721
    Does SQL Server have to be installed on everyone's desktop? Can it not be installed on a dedicated server, and everyone who uses your software can utilize this single instance?
    That which does not kill me postpones the inevitable.

  5. #5
    Join Date
    May 2004
    Posts
    4
    depends on the chosen environment, we have the ability to use a machine as a dedicated server, unfortunately, servers are used as servers. If they are serving our product, they are serving the conflicting product. We also have a lot of "stand-Alone" Clients. Not an option here either. Sorry for being difficult.

  6. #6
    Join Date
    Jul 2003
    Location
    SoCal
    Posts
    721
    Wow.. so the Stand-Alone clients, and the distributed clients both require the full install of SQL Server? Sounds overkill for the Stand-Alone. One idea might be to use Access for the Stand-Alone implementations, and SQL Server for the distributed clients. That might require significant recoding of the install, and the app (to execute SQL vs Access specific statements), but it would probably solve the problem.

    At the same time, it would reduce the cost of your Stand-Alone version (since they won't have to purchase a commerical SQL Server license), be cheaper for your clients, giving you an edge over your competators.
    That which does not kill me postpones the inevitable.

  7. #7
    Join Date
    May 2004
    Posts
    5

    MSDE conflict cont'd

    I work with Geeneus,
    ok, the MSDE (MSDE 2000) is only running on the server, the workstations are not required to be running the server app(sorry about being unclear about this). This in turn, explains why a stand-alone is required to run it as well. Turning the client app to Access is a leap backwards, and not needed. The symptom we are experiencing, is that another database app is grabbing a hold of our database before MSDE can grab it. I suspect BDE (Borland), Paradox, Delphi (also Borland), etc...is just reacting faster and putting a lock on the database even though it is not using it. I know that this BDE can come from many sources, the most common being things like the "Corel" office suite. Anything from Oracle will be using Delphi. Any suggestions?


    Xero

  8. #8
    Join Date
    Jul 2003
    Location
    SoCal
    Posts
    721
    I don't care for Access either, I understand, just trying to think of an option that wouldn't have you writing your own . Is it possible this other app is running as a service? In which case you could simply disable the process.
    That which does not kill me postpones the inevitable.

  9. #9
    Join Date
    May 2004
    Posts
    5

    cont'd

    yea, thats my assumption. I am having huge troubles locating the offending app/service. BDE tends to hide. In most cases the MSDE will install. It is when we try to run the configuration scripts to attach the database is when it blows up. Something allready installed has grabbed ahold of it and locked it.

  10. #10
    Join Date
    May 2004
    Posts
    4

    We fixed it!!

    Good News!!

    Reverend managed to figure out how to work around the problem. I'll let him explain it but just wanted to give you all the good news!!

  11. #11
    Join Date
    May 2004
    Posts
    5

    Solution

    I have discovered a conflict btween what was called MQIS (MSMQ), and is now Active Directory. This MQIS thing came with early versions of Windows, i.e. Win95, Win98, and NT4. It has an installed backbone of SQL 6.5. If, throughout its lifetime, any of these components have been removed, then this issue can arise. Identification can be made by Start -> Programs -> Startup. I have noticed that the MSDE will show as "Service Manager" and the other instance will be called simply SQL Server. Remove SQl server from startup and run your configuration scripts. viola. Be advised that the next time this client runs any exe that calls for that old SQL Server (app in the case of win9x) it will be reactivated in startup and cause this nightmare again.

    Have also seen strange(same) behavior while trying to install the MSDE after the newest version of quickbooks is installed.
    Last edited by Reverend_Xero; 06-09-04 at 11:38.

  12. #12
    Join Date
    May 2004
    Posts
    5

    another issue

    stupid user tricks:Install MSDE to a win98 machine, upgrade to WIN2k or WINXP. Now the database can not be read by the MSDE.

    I believe that the MSDE installes as a application, when you roll up to xp or 2k, you suddenly have services and POOF! we get blown out of the water.
    anyone had any experience with this and have a workaround/fix?

  13. #13
    Join Date
    May 2004
    Posts
    5

    Resolution

    Install MDAC 2.7 then uninstall the MSDE. Then reinstall the MSDE, it will now install as a service rather than an application. (This was tested from 98 to XP, 2000 is still unknown) Then run any attach/repair scripts (ours run auto in our installer).

    -Frank
    Last edited by Reverend_Xero; 08-12-04 at 13:21. Reason: spelling errors

Posting Permissions

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