Announcement

Collapse
No announcement yet.

PB 3.2 File/record locking

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Guest's Avatar
    Guest replied
    Davide,
    Your techinque for multi-user access has worked well for us for over 14 years. Yes 14 years! We do not lock parts of files or records, we just lock the entire file for a very brief moment while we update/add the record, that way any process will only have to wait only a few moments (hardly noticable) to most users on a database app.

    For actual record locking, for example if you are doing a billing run and want to prevent other users accessing a range of records while you batch process them, simply set a single byte flag at the beginning of the record which indicates the record is in use. No need for any record locking, simply filelocking. Remember KISS....

    p.s. I'm know there's a more elegant solution, however this works

    -------------
    Nigel Thomas

    Leave a comment:


  • Davide Vecchi
    replied
    Nigel, thank you very much for the example describing the problem and for the offering of your demo program. Due to the "tecnique" i used, i see from your example that i' m not subject to this MS bug, so i wouldn' t immediately benefit from your demo program. But since true sharing will be needed soon or later, it would be good for me having your program in my hands already. Like you, i feel that MS hasn' t the will to fix any 16-bit related problem, but don' t know why i feel that. It' s also true that it would be a suicide for MS, but they repeatedly shown that they don' t fear the death and that they can' t die. I will follow the talks about the updated redirector hoping it will be for 16-bit programs too.

    Davide Vecchi
    [email protected]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Lance,
    Yes! We have tested the updated REDIRECTOR and this is why we're gobsmacked that the fix was applied to the 32 bit side of the redirector only. Microsofts efforts to force 16bit apps to a 32bit world perhaps? (sorry getting a bit political here)

    We have constant problems with this bug and our only effective solution was to go to NOVELL (which from a support point of view is a much better choice, it just works plain and simple, however it's expensive).

    It's important to note (an I think I've reiterated it in my previous posts) that the problem occurs only during the 'non-extended filesize' / '2 second window' situation.

    A good solution would be to turn off Workstation caching, but we've not found it....

    BTW, The problem exists with Windows 3.11 running REDIRECTOR /FULL. REDIRECTOR /BASIC does not seem to have the problem (I believe /FULL implements caching and /BASIC doesn't)

    -------------
    Nigel Thomas

    [This message has been edited by Nigel Thomas (edited January 19, 2000).]

    Leave a comment:


  • Lance Edmonds
    replied
    Important note: this issue is limited to Windows 95 *client* PC's only.

    Article Q148367 is not on my (older) MSDN CD, but can be reviewed on MS's web site directly at http://support.microsoft.com/support.../Q148/3/67.asp

    I find it hard to believe that the updated redirector does not fix the problems for 16-bit applications... That would be suicidal for MS. Did you test the updated redirector (which can be downloaded directly from the link above)?

    -------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Davide,
    Consider this, I'll use a simple accounts database:
    1.Workstation 1, opens the customer address file, reads in a record for say 'ABC Inc' and changes the phone number, then writes the record back to the file.

    2.Workstation 2, opens the same customer address file, reads in the same 'ABC Inc' account, changes the ZIP code then writes the record back to the file.

    3.Workstation 1, then, re-opens the customer address file, and reads in the account same 'ABC Inc'. Under certian circumstances (see below) Workstation 1 will NOT read from the changed record stored on the filesever, but will read the record cached in its memory since its last write (to change the phone number) and the resultant data will have lost its integrity.

    This will only happen if:
    1.The filesize has not changed at any time. This normally happens when you add records rather than change them.
    2.The time between the first access on Workstation 1 and the second access on Workstaion 1 is not more than 2 seconds
    3.The network cache buffer on Workstation 1 has not been flushed or 'written through'

    This problem has been acknowledged by MS but I beleive their fix only relates to 32 bit programs and not 16 programs.

    To try it, set up a 2 (or more) user + fileserver Windows network and experience it for yourself....

    (I even have a little program to demonstrate the problem if you require it...)



    -------------
    Nigel Thomas

    Leave a comment:


  • Davide Vecchi
    replied
    I had to make a PB 3.5 program "LAN-aware", and i went for the following approach: just relying on trapping error 70 and not using OPEN clauses such as LOCK, SHARED etc. Talking about a Win95 LAN.
    I want to highlight that my approach is very rough, because it' s "version one", because i wanted to hurry myself, because true sharing wasn' t a need, and because the concurrent access to the same file by more users is quite rare.

    The program opens the network files FOR OUTPUT, FOR INPUT or FOR APPEND as needed, with no sharing / locking clauses in the OPEN statement. If the OPEN generates a permission denied error (70), a message informs the user that the file is occupied, and stays waiting for the file to become free (i.e, for the OPEN no longer generating an error), with a timeout; when the file gets free, the execution continues normally.
    So, i lost the possibility for more than one user per time to keep the file opened, but this was not needed, just needed eliminating runtime errors, so i could avoid these SHARE / LOCKED / ACCESS / Microsoft issues. If true sharing will be needed nextly, i will check Michael' s article on BASICally Speaking.
    In my opinion, the above rough need is more common than one can immediately figure out; when one hasn' t to provide sharing, but just has to avoid LAN-related runtime errors, the trend is to start minding about OPEN clauses, potentially getting into the above troubles "for free". Unless this approach hides (to me) unknown problems; i hope it doesn' t; but:

    (quote Lance << "the article explicitly states that applications that may access a file from multiple PC's at the "same instant" should must definately use locking to ensure local file caching does not lead to data loss." >>

    Could this possible loss also apply to when a PB 3.5 EXE just attempts to OPEN (with no clauses) a file that is already open by another PC, without any attempt to read / write data?

    Davide Vecchi
    [email protected]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Lance,
    I think I gave you a b*m steer, so I dragged out my laptop to access MSDN CD's. Check out Q148367. I do not beleive MS have fixed this with 16 bit apps...

    SYMPTOMS
    When you use the Microsoft Client for Microsoft Networks, a file on a Microsoft networking server (such as a Microsoft Windows NT, Windows 95, Microsoft Windows for Workgroups, or Microsoft LAN Manager server) may become damaged or may contain invalid data if multiple workstations access the file at the same time.

    CAUSE
    The network redirector (Vredir.vxd) caches data locally for files it accesses on a Microsoft networking server. If the file size does not change or if the last modified time does not change within a two-second period, the redirector reads file data from the locally stored cache rather than from the file on the server.
    RESOLUTION
    This issue is resolved by the following updated file for Windows 95:

    VREDIR.VXD version 4.00.1112 (dated 2/11/97) and later


    -------------
    Nigel Thomas

    [This message has been edited by Nigel Thomas (edited January 18, 2000).]

    Leave a comment:


  • Lance Edmonds
    replied
    Following up on Nigel's scary warning about data corruption, Microsoft have a MSKB article (Q152186) about the problem - the problem affects "certain applications" that do NOT use locking on a networked PC running Windows 95.

    Fairly vague description, but the article explicitly states that applications that may access a file from multiple PC's at the "same instant" should must definately use locking to ensure local file caching does not lead to data loss.

    -------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Michael Mattias
    replied
    With that article, I included a program (both source and a compiled MS-DOS exe) which would let you open, read and write files and observe the statuses returned by PB. You would select ACCESS and LOCK on-screen when opening the files.

    I know that program was floating around somewhere (it's another public domain thing), but if we need it again, I have it somewhere and can maybe find some place to post it.

    Send me an e-mail if you want it. (Do not "spam proof" your return e-mail address. You get one try with my "reply" button and I don't edit).



    -------------
    Michael Mattias
    Racine WI USA
    [email protected]

    Leave a comment:


  • Lance Edmonds
    replied
    Nigel, is this a recognized MS problem? Which versions (editions) of Windows 95/98 are affected? What about mixed networks? Do you have a KB article number that discusses this problem?

    -------------
    Lance
    PowerBASIC Support
    ( mailto:[email protected][email protected]</A> )

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Are you experiencing this problem across a network? and If so what network are you running, Windows networking with 16 bit clients per chance??

    ...because if you are, there's a major problem with 16 programs running on Windows 95/98 if they are using a Windows(tm) network...

    NT

    -------------
    Nigel Thomas

    [This message has been edited by Nigel Thomas (edited January 16, 2000).]

    Leave a comment:


  • Lance Edmonds
    replied
    Dieny, the particular issue you mention is indeed in the hands of R&D. I have no futher information to offer, except to say that R&D are hard at work! Stay tuned.

    Mike, there will no doubt be an announcment when the Linux compiler is released. Until then (yes, you know the story) we are unable to comment on any aspect of unreleased products.

    -------------
    Lance
    PowerBASIC Support
    ( mailto:[email protected][email protected]</A> )

    Leave a comment:


  • Mike Luther
    replied
    Thanks Lance ..

    The techniques apply to all current PowerBASIC compilers.
    That's what I was waiting to see.

    However .. like most folks, if this changes come LINUX time or
    something like that, *PLEASE* let us po' folk know.. *PLEASE*



    -------------
    Mike Luther
    [email protected]

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Michael, in your article I find the following --

    "... LOCK SHARED to allow all other programs access to the same file."

    and then, on page 4 ---

    "... because, when a record is locked, it is not available to any user for any purpose, even read-only."

    Does this locked state generate the error condition (error 70, I take it) on another workstation? I.e., after UNlocking, the record is once more available to other users in terms of their OPEN (Access xyz) specifications?

    Lance,

    I am still using PbDLL 5.0 -- version 6 is here as well (even paid for!), and I would very much prefer to use that (DDT etc.) -- but, as you know, it gives error 75 (ERRAPI: 87) on the first file OPEN. Eventually you said you would hand it over to R&D, and I have heard nothing since then.

    Is there perhaps an updated version of PbDLL 6.00? Mine goes back to
    July of last year. If so, that might remedy the problem mentioned.

    Leave a comment:


  • Lance Edmonds
    replied
    The techniques apply to all current PowerBASIC compilers.

    -------------
    Lance
    PowerBASIC Support
    ( mailto:[email protected][email protected]</A> )

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Have now received copy of the BASICally Speaking issue for December 1995,
    for the article by Michael Mattias on Fundamentals of Multi-User
    Programming.

    Does this apply equally to PB 3.n for DOS as well as PbDLL 5.0 for Windows?

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Thanks, Michael, I have done so.

    Leave a comment:


  • Michael Mattias
    replied
    To get the text, you need to purchase a reprint of the article.

    IMS has on-line ordering.

    MCM

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Michael, thanks very much. However, the only item I seem to be able to download is a little zip file LIST5-3.zip (or somesuch) which contains three items: Figure1.bas, Multi.bas and Read.Me. These do not seem to be the full story.

    How does one get hold of the text of your article proper ?

    Leave a comment:


  • Michael Mattias
    replied
    You may want to pick up a reprint of my article, "Fundamentals of Multi-User Programming" which appeared in the December, 1995 issue of BASICally Speaking. The article discusses all the ACCESS and LOCK options and includes a bunch of code.

    Reprint info: http://www.infoms.com

    (I have no financial interest in reprint or subscription sales).




    -------------
    Michael Mattias
    Racine WI USA
    [email protected]

    Leave a comment:

Working...
X