none
wifi tablets - how to avoid/recover from wifi interruptions RRS feed

  • Question

  • I have a number of wifi tablets running a very simple program which accesses and modifies a small table on a windows 2012 server.

    The program runs great but sometimes we see interruptions and we get the open file dialog.

    How would one approach this? I don't think "try" or error trapping can solve this.

    Some details:

    The program basically runs a select command initiated with a timer of 30 seconds interval. It updates a little grid. The user then can click a command button which in turn changes a value in the original table.

    Thanks!

    Monday, April 1, 2019 5:16 PM

Answers

  • To avoid the file open dialog you have to SET TEBLEPROMPT OFF.

    But you're right, nothing solves the problem of not having stable WiFi connection. So you still also need to TRY and catch errors and then react correspondingly.

    Using the "Safe Select" technique you'd

    a) NOT bind the grid to the DBF but a READWRITE CURSOR

    b) to refresh TRY a SQL-Select INTO CURSOR TEMPALIAS and then change the grid cursor with ZAP and APPEND FROM DBF("TEMPALIAS")

    c) also TRY your REPLACE or UPDATE

    More ideal solution: A Web service acting on the DBF just serverside, clients only accessing the Webservice. Because your setup is bound to corrupt the DBF at some time, no matter how small it is and stays.

    Bye, Olaf.



    • Edited by OlafDoschke Tuesday, April 2, 2019 12:08 PM
    • Marked as answer by Aleniko2 Friday, April 5, 2019 2:50 AM
    Tuesday, April 2, 2019 6:35 AM
  • Hello,

    in unstable networks we use remote access solutions like RDP (mstsc), Teamviewer, Anydesk, TSPLUS or similar.

    Then a screen freezes, but data corruption usually does not appear.

    And olaf's suggestion and if possible switching from dbf to sql-server (Express is free)

    Best regards

    tom

    • Marked as answer by Aleniko2 Friday, April 5, 2019 2:50 AM
    Tuesday, April 2, 2019 7:42 AM

All replies

  • Sorry for the crazy fonts... I don't know how this happened...
    Monday, April 1, 2019 5:16 PM
  • To avoid the file open dialog you have to SET TEBLEPROMPT OFF.

    But you're right, nothing solves the problem of not having stable WiFi connection. So you still also need to TRY and catch errors and then react correspondingly.

    Using the "Safe Select" technique you'd

    a) NOT bind the grid to the DBF but a READWRITE CURSOR

    b) to refresh TRY a SQL-Select INTO CURSOR TEMPALIAS and then change the grid cursor with ZAP and APPEND FROM DBF("TEMPALIAS")

    c) also TRY your REPLACE or UPDATE

    More ideal solution: A Web service acting on the DBF just serverside, clients only accessing the Webservice. Because your setup is bound to corrupt the DBF at some time, no matter how small it is and stays.

    Bye, Olaf.



    • Edited by OlafDoschke Tuesday, April 2, 2019 12:08 PM
    • Marked as answer by Aleniko2 Friday, April 5, 2019 2:50 AM
    Tuesday, April 2, 2019 6:35 AM
  • Hello,

    in unstable networks we use remote access solutions like RDP (mstsc), Teamviewer, Anydesk, TSPLUS or similar.

    Then a screen freezes, but data corruption usually does not appear.

    And olaf's suggestion and if possible switching from dbf to sql-server (Express is free)

    Best regards

    tom

    • Marked as answer by Aleniko2 Friday, April 5, 2019 2:50 AM
    Tuesday, April 2, 2019 7:42 AM
  • Olaf and Tom; Thanks for your input.

    Right now, I'm doing what Olaf suggested, but without the set tableprompt off, and without error trapping.

    So what happens if I add the tableprompt off and set try catch for my replace and select commands? Would it actually catch, or freeze?

    There is no data corruption. at least not yet. :-)

    Thank you both.

    Tuesday, April 2, 2019 1:48 PM
  • Try..Catch is localized error handling and if you do nothing in the catch block simply means suppressing errors. Not freezing. Code execution continues after endtry.

    You obviously don't have that simplest choice, you would need to react, First off, repeating the SELECT until you get data to display, then secondly repeating the REPLACE to get the data changed.

    And that's where a flaky network access will guarantee DBF file corruption sooner or later, though.

    At some time the REPLACE will not trigger an error you catch but simply cause a file corruption and then every further SELECT and REPLACE will error on that.

    Bye, Olaf.

    Tuesday, April 2, 2019 4:01 PM
  • Hello,

    as Olaf mentioned all this is just "cosmetics", hiding error messages.

    If data is not saved correctly this corrupts data, logically ((partly) missing entrys) or physically (corrupt dbf due to header corruption).

    Logical erros could be trapped with transactions (can be MUCH work) , physical errors not.

    If you think of other problems with dbf in a network (opp.locks, index corruption) I strongly recoomend to switch to a client server system (like MSSQL) or make you app "local" with a remote solution (rdp,..)

    Best regards

    tom

    Thursday, April 4, 2019 7:30 AM
  • These are good thoughts. Thinking deeper about it, the recommended solutions don't depend on the connection to be stable. RDP more so than a MSSQL client/server. If client/server connections are broken you simply get disconnected from the server side itself, it may not recognise or accept your connection handle, it might do even if the connection was cut off, you might also just reestablish a SQL connection. after SQLEXEC failes, but there's noithing going on in the database files that can corrupt them in comparison with acting on a file through a flaky conection. I also wrote about the experience of a wifi network with multiple access points across the floors of a company, in that case connections were flaky in the sense tablets switched the access point (SPID) and MSSQL then does not accept requests coming from anoher SPID. so MSSQL on Wifi also has it's problems.

    RDP less so, you just get errors in refreshing your remote view, as all the code and data is centralized on terminal servers there is no problem there, you put the weak part of the connection where it's less vital for trhe overall stability.

    Another disjoint scenario is one, where tablets use local data, with MS tablets for simplicity that could be local DBFs. There's much more effort in synching, but in a small single table scenario that could simply mean you cyop the whole DBF, validate before you work on it locally, copy it back, albeitnot simply overwriting the original but create a checkin folder and a server side routine to merge changes into the central DBF. You might also not copy back the whole DBF just the changed records. And that could be in the form of XML Diffgram, too. VFP has some tools for that on board, and that would go in the direction of a webservice way of retrieving and updating data.

    There's more to program, but the concept stays a VFP app working on DBFs locally. You stay with the central DBF, which may be important to you and reason to avoid the step of MSSQL client/server migration. RDP also may cause too high client license costs, though AFAIK kjnow (I'm not a MS partner resales person) a few CALS and terminal server are in a usual server OS license.

    Of course you could also think about investing about $100 in better access point hardware and/or tablets with better Wifi and at least check whether their configuration lets them switch SPIDs, insteads force them to use the one necessary for whatever job this is about, eg stocktaking. In the end wifi is not a good way of networking with the file system and a DBF backend, it's also only good for client/server (MSSQL or other RDBMS) in a simple network.

    Bye, Olaf.


    Thursday, April 4, 2019 9:37 AM
  • Thank you all so much for answering in such detail. I really appreciate it.

    Olaf: I did think about the local table solution. I assume by "copy" the table you mean update the server table. Am I correct? Because there is no way to copy a table back to the server if the file is in use by others.

    So if you meant work on a local table and then update the table on the server - am I not risking corruptions here as well?

    Thanks.

    Friday, April 5, 2019 2:50 AM
  • I think about only putting back changes separate and then let a server side process merge this into the server side DBF. If your client app does this it wouldn't be any change from what you're doing right now.

    Bye, Olaf.


    Friday, April 5, 2019 6:22 AM