locked
VFP8 - 32/64 BITS RRS feed

  • Question

  • IS THERE ANY LIMITATION ON VFP8 FOR RUNNING ON:

    1) 64 BITS?

    2) WINDOWWS 2008 - Release 2?

    Monday, July 12, 2010 2:18 PM

Answers

  • VFP9 is working fine and I suppose VFP8 will do so...
    dni
    • Marked as answer by Benny Gabel Monday, July 12, 2010 3:02 PM
    Monday, July 12, 2010 2:43 PM

All replies

  • VFP9 is working fine and I suppose VFP8 will do so...
    dni
    • Marked as answer by Benny Gabel Monday, July 12, 2010 3:02 PM
    Monday, July 12, 2010 2:43 PM
  • This will depend on your data souce.

    As long as you are working with SQL Server or any other ODBC/OLEDB (Qracle,Informix, a.s.o.) accessable database, everything will work as always.

    However, when working with VFP data, you will have to take care, that SMB2 and OpLock are disabled on your 2K8 Server. Otherwise your index files will get destroyed.


    Gruss / Best regards -Tom 010101100100011001010000011110000101001001101111011000110110101101110011
    Monday, July 12, 2010 4:34 PM
    Answerer
  • Tom Borgmann wrote:

    This will depend on your data souce.

    As long as you are working with SQL Server or any other ODBC/OLEDB
    (Qracle,Informix, a.s.o.) accessable database, everything will work
    as always.

    However, when working with VFP data, you will have to take care, that
    SMB2 and OpLock are disabled on your 2K8 Server. Otherwise your index
    files will get destroyed.

    No optimistic locking? This sounds like a major issue!


      Vilco in Italy
      Via NNTP bridge

    Tuesday, July 13, 2010 2:14 PM
  • Vilco in Italy wrote:

    However, when working with VFP data, you will have to take care, that
    SMB2 and OpLock are disabled on your 2K8 Server. Otherwise your index
    files will get destroyed.

    No optimistic locking? This sounds like a major issue!

    I misunderstood your post, probably. You meant that one has to disable SMB2 and OpLock?
    Is OpLock what we call "optimistic locking" in VFP?


      Vilco in Italy
      Via NNTP bridge

    Tuesday, July 13, 2010 2:41 PM
  • Well, it is, as long as you are working with VFP DB.

    As long as SMB2 (can't deactivate OpLocks) is active, this problem might occur.

    When disabling SMB2 and activating SMB1, SMB1's Oplock has to be deactivated.

    I didn't (and won't) have those problems, as we are using Informix as DB Backend since VFP 6.

    The only time, that we use VFP DBs is, by preparing data for Crystal Reports. And those on the fly created DBs don't need indexing as they are way to small.

    However, when searching the web for this problem, you will find that wOOdy and Olaf wrote a lot about this in detail.


    Gruss / Best regards -Tom 010101100100011001010000011110000101001001101111011000110110101101110011
    Tuesday, July 13, 2010 2:55 PM
    Answerer
  • Hi Vilco

    >> Is OpLock what we call "optimistic locking" in VFP? <<
     
    No. It's spelled: "Opportunistic locking" and is not the same as "Optimistic Locking".
     
    Basically it means that if you are opening a file in SHARED mode, and the OS figures that you are the only user, it will cache the file locally as much as possible, thus you (as the only user) have the impression of a very fast network access.  As soon as a second user B accesses the file, that local cache of user A has to get transferred to the server, and caching has to get disabled so that both users see changes of each other instantly. Unfortunately that caching and switching is well known to corrupt indices and databases; you'll find thousands of reports about that on the net.  This is not a FoxPro-Problem, all file-based databases (like FoxPro, Access, Paradox, FileMaker...) are broken by that. Even more unfortunatly, that OpLock speed-fake is the default setting on all major network providers (MS, Novell, Samba), and MS is using it to get users converting to expensive SQL-Server based solutions.
     
     
     

    wOOdy
    Microsoft Visual FoxPro Technology Advisor
    Microsoft "Most Valuable Professional" from 1996 to 2009
    Visit my XING profile! Don't know what XING is?

    *´¨)
    ¸.·´¸.·*´¨) ¸.·*¨)
    (¸.·´. (¸.·` *
    .·`.Visual FoxPro: It's magic !
    (¸.·``··*


     

    Wednesday, July 14, 2010 9:35 AM
  • Jürgen Wondzinski wrote:

    Is OpLock what we call "optimistic locking" in VFP? <<

    No. It's spelled: "Opportunistic locking" and is not the same as
    "Optimistic Locking".

    Basically it means that if you are opening a file in SHARED mode, and
    the OS figures that you are the only user, it will cache the file
    locally as much as possible, thus you (as the only user) have the
    impression of a very fast network access. As soon as a second user B
    accesses the file, that local cache of user A has to get transferred
    to the server, and caching has to get disabled so that both users see
    changes of each other instantly. Unfortunately that caching and
    switching is well known to corrupt indices and databases; you'll find
    thousands of reports about that on the net. This is not a
    FoxPro-Problem, all file-based databases (like FoxPro, Access,
    Paradox, FileMaker...) are broken by that. Even more unfortunatly,
    that OpLock speed-fake is the default setting on all major network
    providers (MS, Novell, Samba), and MS is using it to get users
    converting to expensive SQL-Server based solutions.

    So, in W2K8, one has to disable OpLock to protect DBF indexes from corruption, if I undesrtood clearly.
    Thanks


      Vilco in Italy
      Via NNTP bridge

    Wednesday, July 14, 2010 10:11 AM
  • Hi Vilco,
     
    >> So, in W2K8, one has to disable OpLock to protect DBF indexes from corruption <<
     
    Not only in W2K8. You should apply that to any Server, since OpLocks started to show up with W2000.
     
    The problem only got worse in W2008, since there it is always enabled if you use SMB2 protocol (which is the default in W2008).
     
    Thus in W2008 you need to do two steps:
    a) Disable SMB2, which then falls back to SMB1 
    b) With SMB1 you can disable OpLocks
     
     
    Note to a) Due to some other problems with SMB2, MS provides even a tool to disable SMB2: http://go.microsoft.com/?linkid=9683379  (and http://support.microsoft.com/kb/975517/en-us)
     
    Further information:
     

    wOOdy
    Microsoft Visual FoxPro Technology Advisor
    Microsoft "Most Valuable Professional" from 1996 to 2009
    Visit my XING profile! Don't know what XING is?

    *´¨)
    ¸.·´¸.·*´¨) ¸.·*¨)
    (¸.·´. (¸.·` *
    .·`.Visual FoxPro: It's magic !
    (¸.·``··*


     

    Wednesday, July 14, 2010 1:32 PM
  • Jürgen Wondzinski wrote:

    So, in W2K8, one has to disable OpLock to protect DBF indexes from
    corruption <<

    Not only in W2K8. You should apply that to any Server, since OpLocks
    started to show up with W2000.

    The problem only got worse in W2008, since there it is always enabled
    if you use SMB2 protocol (which is the default in W2008).

    Thus in W2008 you need to do two steps:
    a) Disable SMB2, which then falls back to SMB1
    b) With SMB1 you can disable OpLocks

    You are too kind Woody, thanks.
    One last question, about this sentence in your penultimate post "Basically it means that if you are opening a file in SHARED mode".
    What did you mean with shared? DId you mean VFP's "USE myDBF SHARED" or simply shared in the sense that many user can access it?
    Thanks again


      Vilco in Italy
      Via NNTP bridge

    Thursday, July 15, 2010 7:13 AM
  • Hi Vilco,
     
    >> One last question, about this sentence in your penultimate post "Basically it means that if you are opening a file in SHARED mode". What did you mean with shared? DId you mean VFP's "USE myDBF SHARED" or simply shared in the sense that many user can access it?  <<
     
    It's the way how you open a file (USE EXCLUSIVE versus USE SHARED), it has nothing to do with where the file resides, like "on a network share". For you a "network share" is just another harddisk with a long cable ;), it doesn't make any difference  in terms of fileaccess.
     
     
    If you open any file on a PC (or Network) from any program, you have to tell the Operating Sytem in which mode you open it. Normally you have options like ReadOnly and ReadWrite, which already have some influence on the cache mode. And then there is additionally the Exclusive or Shared mode. If you tell the OS that you want to have exclusive mode, then the OS will not grant file-access to any other process.  In exclusive mode, caching can be very aggressive, since the OS knows that only you are reading/writing to that file, thus the client can buffer a lot of data to speed up the processes.
     
    If you open a file in Shared mode, the server OS has to take care of a lot more things for that file. For each process which opens the file, he has to take note which byte-ranges are used by that process (a byte-range can get locked for Write mode) thus no two processes are writing to the same part of that file. (This is what we know as "RLock" in VFP). If y process changes a part of the file, that information has to get written back to the server-based file ASAP, so that other processes can request that changed information. Thus caching has to be very sensitive, it can store the file locally for speedy reading, but then it also has to synchronize the changed parts from the server.
     
    This is where FoxPro is very, very sophisticated, and why FoxPro is notecibly faster than other DBMSs, when you compare Updates/sec in a networking environment. This is why FoxPro earned a lot of awards in the past...
     
    Now to the OpLock "fun": Additionally to that application-driven caching we now have a OS driven caching, which is done by the network client and the server. As long as you open a file in Shared mode, the client wouldn't cache;  but the OS figures that you are the only user on that file, and therefor it acts like if you had done an Exclusive Opening, and switches to heavily clientbased caching. As soon as a second process accesses the file, the server has to notify the first client to write back all changes immediately and to switch back to shared-mode chaching.
     
    Unfortunatly, those network-clients have no idea what's going on inside a file, they just copy content back and fore.
     
    And that's where the problem with file-based DBMSs starts, and what I personally suspect as the main problem with the OpLocks technology: In contrast to an Excel file, which is just transferred at a whole, a DBF is always locked and written in segments (byte-areas). And one of the special things in all xBase DMBS is the technique of "Dirty Reads" to overcome the blocking of the OS: Normally, if you lock a byte-range (or "Record" in VFP speak) of a file for your own use, then no other process is allowed to access that area. That effect would be very bad, if you would just BROWSE that DBF from another workstation: The BROWSE would not be able to just read that byterange and display it, it would just hang for some time and then skip over that part. In a heavily used DBF the user-experience would be very bad, since you couldn't just page fluently through your BROWSE any more.  
    Thus all xbase products developed that "DirtyRead" way of fooling the OS: They do not lock the real record area, but just lock a placeholder at the end of the file. Thus if you monitor the network traffic you can see, that if you lock record number 10 in a dbf, then VFP will actually lock a single byte at position 2Gbytes - 10. 2Gbytes is the maximum size of a DBF, thus some of the theoretically last records of a DBF are not usable since their byte-area is used as locking-flags (You can see the formula in my "DBF-Resizer" tool at http://code.msdn.microsoft.com/FoxPro/Release/ProjectReleases.aspx?ReleaseId=126) The real data-record is never locked, therefor all processes can easily read that filepart. And IMHO this is what gets the network clients confused: They do see the locks at the end of the file and transfer that changes back to the server, but they don't realize the other write activities in the middle of the file.
     
    Unfortunately no one at Microsoft was willing to look at that potential problem solution, thus to keep your data intact, you definitely need to either disable OpLocks completely.
     
    Hmm, I just had another idea:
    ...or you need to run a server process having all files opened, thus any client will always be the second user, thus no OpLock caching would be done. Ie. a simple VFP-App, doing an ADIR() on all DBFs and opening them in Shared mode would be efficienty switch off the effect. You'll still need to figure out how to deal with the necessity to optionally really gain exclusive access from one client though, but it could be doable.
     
     
     
     
     
     
     
     

    wOOdy
    Microsoft Visual FoxPro Technology Advisor
    Microsoft "Most Valuable Professional" from 1996 to 2009
    Visit my XING profile! Don't know what XING is?

    *´¨)
    ¸.·´¸.·*´¨) ¸.·*¨)
    (¸.·´. (¸.·` *
    .·`.Visual FoxPro: It's magic !
    (¸.·``··*


     

    Thursday, July 15, 2010 8:49 AM
  • Jürgen Wondzinski wrote:

    One last question, about this sentence in your penultimate post
    "Basically it means that if you are opening a file in SHARED mode".
    What did you mean with shared? DId you mean VFP's "USE myDBF
    SHARED" or simply shared in the sense that many user can access it?

    It's the way how you open a file (USE EXCLUSIVE versus USE SHARED),
    it has nothing to do with where the file resides, like "on a network
    share". For you a "network share" is just another harddisk with a
    long cable ;), it doesn't make any difference in terms of fileaccess.


    If you open any file on a PC (or Network) from any program, you have
    to tell the Operating Sytem in which mode you open it. Normally you
    have options like ReadOnly and ReadWrite, which already have some
    influence on the cache mode. And then there is additionally the
    Exclusive or Shared mode. If you tell the OS that you want to have
    exclusive mode, then the OS will not grant file-access to any other
    process. In exclusive mode, caching can be very aggressive, since the
    OS knows that only you are reading/writing to that file, thus the
    client can buffer a lot of data to speed up the processes.

    If you open a file in Shared mode, the server OS has to take care of
    a lot more things for that file. For each process which opens the
    file, he has to take note which byte-ranges are used by that process
    (a byte-range can get locked for Write mode) thus no two processes
    are writing to the same part of that file. (This is what we know as
    "RLock" in VFP). If y process changes a part of the file, that
    information has to get written back to the server-based file ASAP, so
    that other processes can request that changed information. Thus
    caching has to be very sensitive, it can store the file locally for
    speedy reading, but then it also has to synchronize the changed parts
    from the server.

    This is where FoxPro is very, very sophisticated, and why FoxPro is
    notecibly faster than other DBMSs, when you compare Updates/sec in a
    networking environment. This is why FoxPro earned a lot of awards in
    the past...

    Now to the OpLock "fun": Additionally to that application-driven
    caching we now have a OS driven caching, which is done by the network
    client and the server. As long as you open a file in Shared mode, the
    client wouldn't cache; but the OS figures that you are the only user
    on that file, and therefor it acts like if you had done an Exclusive
    Opening, and switches to heavily clientbased caching. As soon as a
    second process accesses the file, the server has to notify the first
    client to write back all changes immediately and to switch back to
    shared-mode chaching.

    Unfortunatly, those network-clients have no idea what's going on
    inside a file, they just copy content back and fore.

    And that's where the problem with file-based DBMSs starts, and what I
    personally suspect as the main problem with the OpLocks technology:
    In contrast to an Excel file, which is just transferred at a whole, a
    DBF is always locked and written in segments (byte-areas). And one of
    the special things in all xBase DMBS is the technique of "Dirty
    Reads" to overcome the blocking of the OS: Normally, if you lock a
    byte-range (or "Record" in VFP speak) of a file for your own use,
    then no other process is allowed to access that area. That effect
    would be very bad, if you would just BROWSE that DBF from another
    workstation: The BROWSE would not be able to just read that byterange
    and display it, it would just hang for some time and then skip over
    that part. In a heavily used DBF the user-experience would be very
    bad, since you couldn't just page fluently through your BROWSE any
    more.
    Thus all xbase products developed that "DirtyRead" way of fooling the
    OS: They do not lock the real record area, but just lock a
    placeholder at the end of the file. Thus if you monitor the network
    traffic you can see, that if you lock record number 10 in a dbf, then
    VFP will actually lock a single byte at position 2Gbytes - 10.
    2Gbytes is the maximum size of a DBF, thus some of the theoretically
    last records of a DBF are not usable since their byte-area is used as
    locking-flags (You can see the formula in my "DBF-Resizer" tool at
    http://code.msdn.microsoft.com/FoxPro/Release/ProjectReleases.aspx?ReleaseId=126)
    The real data-record is never locked, therefor all processes can
    easily read that filepart. And IMHO this is what gets the network
    clients confused: They do see the locks at the end of the file and
    transfer that changes back to the server, but they don't realize the
    other write activities in the middle of the file.

    Unfortunately no one at Microsoft was willing to look at that
    potential problem solution, thus to keep your data intact, you
    definitely need to either disable OpLocks completely.

    Hmm, I just had another idea:
    ...or you need to run a server process having all files opened, thus
    any client will always be the second user, thus no OpLock caching
    would be done. Ie. a simple VFP-App, doing an ADIR() on all DBFs and
    opening them in Shared mode would be efficienty switch off the
    effect. You'll still need to figure out how to deal with the
    necessity to optionally really gain exclusive access from one client
    though, but it could be doable.

    Very inetersting, Woody, thanks a lot for clarifying!


      Vilco in Italy
      Via NNTP bridge

    Thursday, July 15, 2010 2:00 PM