Results 1 to 8 of 8
  1. #1
    Join Date
    Mar 2008
    Posts
    4

    Question Unanswered: Make app work in multi-user environment

    I'm trying to get an old Paradox application (from 1999-2002) to work in a networked, 2-user environment. The application is designed to work in either single-user or multi-user mode, but we cannot find our multi-user registration key, so the application currently thinks it is running in single-user mode. (We purchased multi-user registration years ago, but didn't end up needing it until now, but cannot locate our key.)

    This application is not being supported, and I cannot find anybody who still claims to own it. The company that developed & supported it was bought out by another company, support expired and the product was dropped, and then that company was bought out by yet another company. Multiple attempts to contact former owners or support have led nowhere, and I can't even find anybody else out there who still uses the application.

    So, as far as I am concerned, I should be able to do whatever it takes to make this application work properly, including applying any work-arounds or fixes that I can find.

    The data for this application is stored on PC1 (acting as the server), but both PC1 and PC2 will access it simultaneously. PC1 and PC2 both have the application installed, and each PCs BDE point to the data identically.

    Folder Configuration:
    • Data is stored on PC1 in C:\cwnet\data
    • C: on PC1 is shared.
    • PC1 and PC2 have drive G: mapped to \\server\c


    BDE Configuration (PC1 & PC2):
    • Net Dir = G:
    • Data Dir = G:\cwnet\data
    • Local Share = True


    Private Folders:
    • I have confirmed that the application is using the user's Temp folder on each PC (documents and settings/user/local settings/temp) as the private folder


    .LCK and .NET files:
    • PDOXUSRS.NET appears as expected on the root of PC1's C: drive (mapped to G: on both PCs)
    • Both PDOXUSRS.LCK and PARADOX.LCK appear on PC1 in C:\cwnet\data
    • Both PDOXUSRS.LCK and PARADOX.LCK appear in user's temp folder on PC currently running application


    The problem: Once the application is started on one PC, starting the application on the other PC gives the error "File is locked. Table: CWCLINIC.DB. User: ____"

    My thoughts: Could the application be putting a lock on all tables (or CWCLINIC.DB) just to prevent the user from being able to share the data? Perhaps this wouldn't happen if the application acknowledged a multi-user registration key?

    Options I've thought of:
    1. Deleting C:\cwnet\data\PDOXUSRS.LCK every time the app is opened: As a test, I deleted the PDOXUSRS.LCK in the data folder after running the application the first time, and I was then able to run it on both PCs. Adding & removing data worked well, with changes showing up in the application on both PCs. But I worry that this will cause problems down the road that might not show up in testing. What's the probability of this being a problem?
    2. Making C:\cwnet\data\PDOXUSRS.LCK read-only: Haven't tried it yet, but I figure this would have the same effect as deleting the file each time
    3. Editing C:\cwnet\data\PDOXUSRS.LCK somehow: If the application is putting a fake lock on one or more tables to prevent multi-user access, can PDOXUSRS.LCK be modified somehow to initially remove that fake lock, but leaving the file in place to be used when real locks are required?
    4. Reverse-Engineering the Application: I haven't found anything like this yet, but is there a way I can reverse-engineer the application and examine the code to discover whether or not I can force it to allow multi-user usage? It's the option requiring the most work, but it would be worth it.


    Any advice or suggestions would be much appreciated.
    Last edited by BenjaminRay; 03-12-08 at 15:01.

  2. #2
    Join Date
    Dec 2007
    Posts
    366
    Ben.. you sure went thru a lot of work, just to discover that you had a stray, bad lock file on one machine (g).. but you're fine now.. your basic knowledge is pretty good.. however, a few comments..

    first, extra serial numbers mean purchasing extra copies of paradox.. you can do that on my web site, but it looks like you don't need to..

    second.. paradox automatically protects you from duplicate access in a shared app.. that's what the lock files are for.. but it can't protect you from your "server" locking up while it's being used as a workstation.. that's actually one of the dumbest things you can do with a shared database.. for a few hundred bucks, you should get a third machine and have a real "server".. I'm sure your data is worth a lot more than that..

    third.. there's no way of knowing from here, if the app itself is manually placing locks that will stop you from sharing the way you want to.. yes, people sometimes write apps that specifically place stronger locks than needed and/or write processes in a manner that requires exclusive access because they never considered multi-user issues.. only time will tell..

    fourth.. don't ever try any of the other "options" you suggested.. all of them will have disasterous results..

    finally.. next time you need help, go to the community forums, not here.. most of the active, experienced developers hang out there every day.. I just monitor this forum occasionally, looking for strays like you, and happened to cruise thru here right after you did.. see my Links page..
    --
    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
    Mar 2008
    Posts
    4

    Well, sort of - but more questions...

    Thanks for your reply. I've added some more comments throughout.

    Quote Originally Posted by Steve Green
    Ben.. you sure went thru a lot of work, just to discover that you had a stray, bad lock file on one machine (g).. but you're fine now..
    There wasn't a stray, bad lock file - I should have worded that differently. What I meant is that I tried deleting the newly-created lock file from the data directory right after opening the application. I opened the app on PC1 (acting as the server), manually deleted the lock file, and then was able to open the app on PC2. The two versions operated together very well, but I'm weary of deleting the lock file every time the app is opened, not knowing what effect this may have.

    Quote Originally Posted by Steve Green
    first, extra serial numbers mean purchasing extra copies of paradox.. you can do that on my web site, but it looks like you don't need to..
    I don't think I need extra serial #s for Paradox. This application was sold commercially by a software company, and the application has a registration component that allows single- or multi-user operation. The application itself required registration, and although we later purchased their 2-user package, we can only locate the 1-user key. Finding our old 2-user key might make this application work like a charm, but we may never know that.

    Quote Originally Posted by Steve Green
    second.. paradox automatically protects you from duplicate access in a shared app.. that's what the lock files are for..
    Everything I've read about Paradox and the BDE indicate that duplicate access is possible, even with the PDOXUSRS.LCK file present in the data directory.

    Quote Originally Posted by Steve Green
    but it can't protect you from your "server" locking up while it's being used as a workstation.. that's actually one of the dumbest things you can do with a shared database.. for a few hundred bucks, you should get a third machine and have a real "server".. I'm sure your data is worth a lot more than that..
    When I (if ever) get reliable multi-user access to this application, the data will reside on the office server, separate from the workstations. But I've only got 2 PCs tied up in the testing operation.

    Quote Originally Posted by Steve Green
    third.. there's no way of knowing from here, if the app itself is manually placing locks that will stop you from sharing the way you want to.. yes, people sometimes write apps that specifically place stronger locks than needed and/or write processes in a manner that requires exclusive access because they never considered multi-user issues.. only time will tell..
    The application was designed to run in either single-user or multi-user mode. We are currently running it in single-user mode. Could using stronger db locks be the developer's way of enforcing single-user operation?

    Quote Originally Posted by Steve Green
    fourth.. don't ever try any of the other "options" you suggested.. all of them will have disasterous results..
    But about reverse-engineering of the application, is that even possible? (I would just love to get my hands on the source.)

    And what about examining the contents of a lock file? If I could know from the lock file what tables are locked, that would tell me if the locking is being done to protect currently-accessed tables, or to prevent multi-user operation.

    Thanks again.

    Ben

    PS - Can you point me to the community forumns you're referring to?
    Last edited by BenjaminRay; 03-12-08 at 14:55.

  4. #4
    Join Date
    Dec 2007
    Posts
    366
    I'll answer the last question first.. go to my links page.. halfway down the page are the newsgroup links.. or go to www.thedbcommunity.com and get there from the community web site itself..

    now.. one more generic comment before I go thru your list.. in your config stuff, all is well except one thing.. shouldn't put the net file or anything writable in the root of a drive, for a number of reasons.. that's a habit that could bite you one day..

    and, your original questions, which I addressed in my original response:


    > Could the application be putting a lock on all tables (or CWCLINIC.DB) just to prevent the user from being able to share the data? <

    yes..


    > Perhaps this wouldn't happen if the application acknowledged a multi-user registration key? <

    also yes.. paradox itself is automatically multi-user capable.. but certain actions, by design, require exclusive access.. i.e. you don't need a full lock on the main data table to view it, but the developer could have manually placed full locks as his way of enforcing "single user" logic..


    now your follow-up questions..


    > The two versions operated together very well, but I'm weary of deleting the lock file every time the app is opened, not knowing what effect this may have. <

    lock files are automatically placed in any shared directory that is being touched.. if you log in on PC1, and it touches a table, it creates lock files in that folder.. the lock files are deleted when the last user leaves the folder..

    you can't delete the lock files if PC1 is still touching anything, or if another user came in and started touching things.. so, if you're deleting a good lock file as noted, that means it *is* the app doing it, not paradox and/or your configuration..


    > Finding our old 2-user key might make this application work like a charm, but we may never know that. <

    methinks we now know.. (g)


    > Everything I've read about Paradox and the BDE indicate that duplicate access is possible <

    I meant destructive concurrent access, not normal concurrent access..


    > the data will reside on the office server, separate from the workstations <

    good.. that's very important.. when you use the server as a workstation, the workstation can cause destructive behavior that can impact the whole network.. I'm sure you know that..


    > Could using stronger db locks be the developer's way of enforcing single-user operation? <

    generically, yes.. specifically to this case, evidently also yes..


    > But about reverse-engineering of the application, is that even possible? (I would just love to get my hands on the source.) <

    if you have the source, changes can be made.. if not, no, you can't "un-compile" paradox code..


    > And what about examining the contents of a lock file? <

    yes, it can tell you what locks are currently in place.. and that can give clues as to the developers' logic.. but you can't edit the lock file and change things.. once the lock is in place, it's too late to change it..

    my guess is that, yes, the developer is using locks to control your app.. so you need to find that registration key, or live with "single-user" access..

    hopefully, you're giving serious thought to enacting a replacement strategy for that app.. aside from the problems with the app itself, paradox is a dead platform, and there are only a handful of people like me left..
    --
    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
    Mar 2008
    Posts
    4

    Thanks again!

    I will also reply in reverse order.

    Quote Originally Posted by Steve Green
    hopefully, you're giving serious thought to enacting a replacement strategy for that app.. aside from the problems with the app itself, paradox is a dead platform, and there are only a handful of people like me left..
    Absolutely. In fact, I'd rather be replacing it right now (instead of trying to configure multi-user access), but we haven't yet settled on a replacement, and our need for multi-user access is more immediate.

    Quote Originally Posted by Steve Green
    > Could the application be putting a lock on all tables (or CWCLINIC.DB) just to prevent the user from being able to share the data? <

    yes..

    > Perhaps this wouldn't happen if the application acknowledged a multi-user registration key? <

    also yes.. paradox itself is automatically multi-user capable.. but certain actions, by design, require exclusive access.. i.e. you don't need a full lock on the main data table to view it, but the developer could have manually placed full locks as his way of enforcing "single user" logic..

    lock files are automatically placed in any shared directory that is being touched.. if you log in on PC1, and it touches a table, it creates lock files in that folder.. the lock files are deleted when the last user leaves the folder..

    you can't delete the lock files if PC1 is still touching anything, or if another user came in and started touching things.. so, if you're deleting a good lock file as noted, that means it *is* the app doing it, not paradox and/or your configuration..

    my guess is that, yes, the developer is using locks to control your app.. so you need to find that registration key, or live with "single-user" access..
    I'd like to beat this dead horse around the bush just one more time here. When the app starts up, no table editing is going on - the user is presented with a welcome screen and has to navigate through some menus. Yet, the lock file is present. In fact, no matter what you are doing, the lock file exists until the second you close the application.

    On very rough inspection (with Notepad), just about every table in the database is named in the lock file when the app is first opened, and the file remains virtually identical throughout the use of the application. Surely this is not a result of data actually being written to the tables!

    So, IF the developer is using the lock file to force single-user logic, and IF I delete that lock file after starting the application, would the BDE still be able to create and remove lock files as required when actually required?

    Thanks for your patience.

  6. #6
    Join Date
    Dec 2007
    Posts
    366
    > On very rough inspection (with Notepad), just about every table in the database is named in the lock file when the app is first opened, and the file remains virtually identical throughout the use of the application. Surely this is not a result of data actually being written to the tables! <

    you are 100% correct.. either the app is opening all the files, for whatever reason, or there's a hidden form being opened, with all those files in the data model.. either way, you've got open tables.. the essential issue is, what kind of locks are being placed, and why?

    in my apps, there are three control tables opened at startup, and they stay open during the life of the session.. the concept itself is normal..

    but.. you said you could delete the lock file.. you can't do that unless there's no open activity..


    > So, IF the developer is using the lock file to force single-user logic, and IF I delete that lock file after starting the application, would the BDE still be able to create and remove lock files as required when actually required? <

    if you somehow manage to delete the lock file while it's in use, paradox will GP and crash.. if you delete the lock file when there's no activity, it'll be re-created as needed..

    one quick side-question.. what's the command line being used to fire off the app from the shortcut on the desktop?
    --
    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

  7. #7
    Join Date
    Mar 2008
    Posts
    4
    Quote Originally Posted by Steve Green
    but.. you said you could delete the lock file.. you can't do that unless there's no open activity..

    if you somehow manage to delete the lock file while it's in use, paradox will GP and crash.. if you delete the lock file when there's no activity, it'll be re-created as needed..
    Yes, the lock file is deleted without problem, assuming I'm not actually doing anything in the application. (I got an error message trying to delete it while editing a table.) So that may confirm that the initial locks created on startup are not actually required, as they were easily deleted. And it also confirms that Paradox won't let me delete a lock file when one is actually required!

    This will obviously require some extensive testing, but I may be in luck.

    Quote Originally Posted by Steve Green
    one quick side-question.. what's the command line being used to fire off the app from the shortcut on the desktop?
    Well, after wrapping my head around things a little more today, I've finally come to the realization that the application itself was likely created in C++ or an early version of VB. The application uses a Paradox database, and the BDE makes the connection between the two.

    The application is executed from an EXE named after it.

    I'm not at all familiar with Paradox, so it has taken me a while to put the pieces together.

    And, of course, I really appreciate your help.

  8. #8
    Join Date
    Dec 2007
    Posts
    366
    > Yes, the lock file is deleted without problem, <

    good.. you are describing normal file use and file deletion behavior.. this confirms many of the things we've discussed..

    > The application is executed from an EXE named after it. <

    wow.. didn't see that coming (g).. so much for having any code to dig into..
    --
    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
  •