Announcement

Collapse

New Sub-Forum

In an effort to help make sure there are appropriate categories for topics of discussion that are happening, there is now a sub-forum for databases and database programming under Special Interest groups. Please direct questions, etc., about this topic to that sub-forum moving forward. Thank you.
See more
See less

PB 3.2 File/record locking

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

  • PB 3.2 File/record locking

    PB 3.2 for DOS.

    Quite a number of years ago, before I had e-mail, I enquired by
    telephone (I spoke to Lloyd Smith on several occasions) on the
    question of file locking on a network. Many words were exchanged, but
    ultimately I was given "Access READ WRITE SHARED" as the combination
    which gives neither compile time nor run time problems. The kdd$ below
    is a path.

    Open kdd$+"DEBTORS" Access Read Write Shared As #7 Len=450

    field #7, 30 As dco$, 8 As ddt$,20 As dcp$,15 As dtl$,15 As dfx$
    field #7, 88 As z$, 15 As dtx$,15 As dvt$,30 As dp1$,30 As dp2$
    field #7,178 As z$, 30 As dp3$,30 As dp4$, 6 As dx1$, 6 As dx2$
    field #7,250 As z$, 10 As dcr$,10 As d30$,10 As d60$,10 As d90$
    field #7,290 As z$, 10 As d20$,10 As d50$,10 As d80$, 5 As dtm$
    field #7,325 As z$, 5 As dtd$, 5 As din$, 2 As dpw$,20 As dct$
    field #7,357 As z$, 10 As dlm$,24 As dsr$,15 As dar$,10 As dua$
    field #7,416 As z$, 1 As dcx$,10 As dob$, 3 As dlv$, 4 As dqn$
    field #7,434 As z$, 5 As dkm$, 4 As dsd$, 3 As dxx$, 4 As dun$

    All logic aside for the moment, this has been running for about seven
    years (ALL files being opened in this fashion) at a number of user
    sites. What problems there were, were very rarely disk file related,
    and by far the most were simply due to the odd condition not catered
    for.

    Now, in response to a user enquiry (they had encountered file
    corruption in a known set of circumstances), I have tried to use:

    To only READ, and permit other workstations to also read, but not
    write --

    Open kdd$+(filename) Access READ Lock WRITE As #x

    To read AND write, as when file maintenance is performed, and permit
    other users NO access to the record --

    Open kdd$+(filename) Access READ WRITE Lock READ WRITE As #x

    In all cases only RECORDS are locked before access and immediately
    afterwards unlocked, except in the case of "maintenance" (read/write).
    The file is closed as well, except in the "read write" case, where
    this is not done until the record has been refiled and unlocked.

    Only the two modules in question were modified in this way and sent
    to the user site, with interesting results. Now, when two workstations
    both use the "read" only (no write) module, and one of these selects
    an account from the menu AND accesses that account and stays there,
    then, when the second station tries to select one likewise (a different
    record), an error 70 (access denied) occurs, and it keeps on retrying,
    using RESUME. The moment the first station exits its record and returns
    to the menu, the second user immediately gains access. All this when
    only RECORD locking is used, as in --

    da%=dr%(sb%+op%-1)
    Lock #7,da%
    Get #7,da%
    UnLock #7,da%

    Is there a hole in the logic, or is it twisted logic? The PB examples
    do describe these things, but then proceeds to give examples with no
    file or record locking illustrations.

    What is the correct way in the various combinations of Access READ
    and/or WRITE and Lock READ and/or WRITE situations? There are random,
    binary and a few sequential files involved. The binary files are locked
    "from/to byte". In the case of sequential files the whole file is
    locked.

  • #2
    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]
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      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 ?

      Comment


      • #4
        To get the text, you need to purchase a reprint of the article.

        IMS has on-line ordering.

        MCM
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Thanks, Michael, I have done so.

          Comment


          • #6
            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?

            Comment


            • #7
              The techniques apply to all current PowerBASIC compilers.

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

              Comment


              • #8
                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.

                Comment


                • #9
                  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]
                  Mike Luther
                  [email protected]

                  Comment


                  • #10
                    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> )
                    Lance
                    mailto:[email protected]

                    Comment


                    • #11
                      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).]

                      Comment


                      • #12
                        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> )
                        Lance
                        mailto:[email protected]

                        Comment


                        • #13
                          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]
                          Michael Mattias
                          Tal Systems Inc. (retired)
                          Racine WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            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>
                            Lance
                            mailto:[email protected]

                            Comment


                            • #15
                              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).]

                              Comment


                              • #16
                                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]

                                Comment


                                • #17
                                  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

                                  Comment


                                  • #18
                                    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>
                                    Lance
                                    mailto:[email protected]

                                    Comment


                                    • #19
                                      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).]

                                      Comment


                                      • #20
                                        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]

                                        Comment

                                        Working...
                                        X