Visual FoxPro Developer Center > Visual FoxPro Forums > Visual FoxPro General > Not sure if I can celebrate yet let me know
Ask a questionAsk a question
 

AnswerNot sure if I can celebrate yet let me know

  • Thursday, November 05, 2009 10:04 PMLarry_Nuñez Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    After putting my form in private datasession  I put the environment tables with no buffering and I have no problem opening forms or recording data. Will this bring me trouble later if I implement this for multiuse purposes? I use the flock command to control access to data and they work well.

Answers

All Replies

  • Thursday, November 05, 2009 10:54 PMCetinBasozMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Maybe you should spend some time on reading and understanding the difference between buffering vs non-buffering, flock() etc. and do many tests before celebrating.
  • Friday, November 06, 2009 4:00 AMNaom Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Premature celebrating is the root of all evil in programming :)))



    Premature optimization is the root of all evil in programming.

    Donald Knuth, repeating C. A. R. Hoare

    My blog
  • Friday, November 06, 2009 10:51 AMAndyKrMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    After putting my form in private datasession  I put the environment tables with no buffering and I have no problem opening forms or recording data. Will this bring me trouble later if I implement this for multiuse purposes? I use the flock command to control access to data and they work well.

    Explicit locking is always a source of problems. A better approach is to use local buffering.

    Take a look at the following blog articles. They explain how to use buffering in VFP.
    Buffering and Locking in Visual FoxPro - an Overview (http://weblogs.foxite.com/andykramek/archive/2005/10/18/948.aspx)
    Handling buffered data in Visual FoxPro (http://weblogs.foxite.com/andykramek/archive/2005/12/27/1077.aspx)
    -- Andy Kramek