Hi everyone..in one of my days using my application, there is this instance that The switch hub was accidental pulled from the power outlet, so all client computers were disconncted from the "server" computer... My question is, is there a way or code that could check the lan connection firs before reading or appending? Is try catch ok to use? Or is it even worth doing testing Lan connection everytime users access to tables? Thanks
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Check LAN connection... 2
- Thread starter Mandy_crw
- Start date
mjcmkrsr
Technical User
- Nov 30, 2010
- 875
Hi Mandy,
I assume that you have some kind of SOHO with all your hardware in one small building. If that's the case
[ul]
[li]Hardware[/li]
[/ul]
You may want to consider to store all your equipment (server, switch, router, ...) in a rack, key lock it and don't let anybody touch it
You may also want to consider to have a power generator installed (see your former eMail about power failures)
[ul]
[li]LAN[/li]
[/ul]
If you try to open a DBC/DBF and there is no LAN connection VFP simply doesn't open it - maybe yielding an error message like "File not found"
If the file is open and you unplug the LAN connection VFP yields "Cannot read the File ..."
If the file is open and you were writing to it, while the LAN connection is interrupted, well this is prone for corruption - I hope you have a backup
If your equipment is spread over several premises, you may want to ask an IT technician for assistance
Btw there is a nice little app that shows the active/dead LAN connections
hth
MarK
I assume that you have some kind of SOHO with all your hardware in one small building. If that's the case
[ul]
[li]Hardware[/li]
[/ul]
You may want to consider to store all your equipment (server, switch, router, ...) in a rack, key lock it and don't let anybody touch it
You may also want to consider to have a power generator installed (see your former eMail about power failures)
[ul]
[li]LAN[/li]
[/ul]
If you try to open a DBC/DBF and there is no LAN connection VFP simply doesn't open it - maybe yielding an error message like "File not found"
If the file is open and you unplug the LAN connection VFP yields "Cannot read the File ..."
If the file is open and you were writing to it, while the LAN connection is interrupted, well this is prone for corruption - I hope you have a backup
If your equipment is spread over several premises, you may want to ask an IT technician for assistance
Btw there is a nice little app that shows the active/dead LAN connections
hth
MarK
Mike Lewis
Programmer
I endorse Mark's suggestion. I have used that utility to help deal with various network connection issues. It works well.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
-
1
- #4
Chris Miller
Programmer
First, I agree with the advice to up your hardware. At best it's not possible your switch hub is "accidentally" pulled from the power outlet. The least you can do is label the plugs and point out that this has to stay in.
If a hub is turned off this way file corruption only will occur if that happens in the moment of writing. If you already have a file open and then start writing after the switch already is off, surely errors like "file not found" will occur, but since you have no connection to the server and file, at that stage there can be no harm done to the file, it stays as it was before you even began to try changing it. So the only harmful situation is when the switch is pulled from power while you write.
As MarK already said there are tools scanning the network, but you can't program on the assumption your LAN is lost. You can, of course, make a check at startup, but assume for a moment you try to avoid the situation the LAN goes away while you write, all you can do is check the LAN is available before you write and then write. In which case the worst scenario of the LAN going off while you write still can happen. So really, there is no point in checking the LAN from your software while it runs. And, well, checking the LAN at startup is done by opening the database or tables. If that fails, you get errors, but also can't harm the database files as you just didn't get at them and they stay as they currently are. What can be done to not get the technical error messages is error-handling, of course, and handling any error pointing out the tables you want to open are currently not available in user friendlier messages.
The only other thing you can do to concentrate the write operations to the least time possible is to use buffering and more important transactions. Because in a transaction all writes are not changing the DBF files unless you finally say END TRANSACTION. This then concentrates changes to the DBF files in the shortest possible time and also writes out whatever number of changes in whatever many tables you changed with any code since BEGIN TRANSACTION.
To get one thing straight from the get-go: Transactions technically are not making buffering necessary, buffering s just a prerequisite for usage of TABLEUPDATE(), but if you use transactions without also buffering changes, you will have a hard time keeping all changes a user makes from the tables before starting the transaction. You can't start a transaction on non-buffered DBFs at the init of a form and let the user work on the DBFs for say 5 minutes before they finally save and end their transaction, as that locks out other users. Not only from single records but from whole tables. So you need to combine the way of buffering of changes and of transactions to use them as they are intended to be used: Just starting the transaction before the first change you write out with TABLEUPDATE() and ending the transaction after the last TABELUPDATE(), if it takes multiple TABLEUPDATE()s for multiple tables.
Notice that even with a transaction not changing any DBF before you finally issue END TRANSACTION in your code, that does also not concentrate all writes to a single point in time. When finally END TRANSACTION is done, that just merges all queued-up file changes from that point on and has a duration that becomes longer with the number of changes you accumulated since BEGIN TRANSACTON. And it's still prone to failing if a power outage happens during that time. So in the end you can't prevent being prone to power outages with any coding, not even with transactions.
From the perspective of how much time is lost for the user needing to repeat his work no buffering and transactions mean less harm, as all changes are put into the tables right away, but then you also are more prone to corruption at each point you write. And in the end, a corrupt table that's not just having the simple defect of a mismatch in header record count and file size, but has a problem within a memo field or a whole section of the dbf overwritten with zero bytes, is an uglier problem than the time loss.
Chriss
If a hub is turned off this way file corruption only will occur if that happens in the moment of writing. If you already have a file open and then start writing after the switch already is off, surely errors like "file not found" will occur, but since you have no connection to the server and file, at that stage there can be no harm done to the file, it stays as it was before you even began to try changing it. So the only harmful situation is when the switch is pulled from power while you write.
As MarK already said there are tools scanning the network, but you can't program on the assumption your LAN is lost. You can, of course, make a check at startup, but assume for a moment you try to avoid the situation the LAN goes away while you write, all you can do is check the LAN is available before you write and then write. In which case the worst scenario of the LAN going off while you write still can happen. So really, there is no point in checking the LAN from your software while it runs. And, well, checking the LAN at startup is done by opening the database or tables. If that fails, you get errors, but also can't harm the database files as you just didn't get at them and they stay as they currently are. What can be done to not get the technical error messages is error-handling, of course, and handling any error pointing out the tables you want to open are currently not available in user friendlier messages.
The only other thing you can do to concentrate the write operations to the least time possible is to use buffering and more important transactions. Because in a transaction all writes are not changing the DBF files unless you finally say END TRANSACTION. This then concentrates changes to the DBF files in the shortest possible time and also writes out whatever number of changes in whatever many tables you changed with any code since BEGIN TRANSACTION.
To get one thing straight from the get-go: Transactions technically are not making buffering necessary, buffering s just a prerequisite for usage of TABLEUPDATE(), but if you use transactions without also buffering changes, you will have a hard time keeping all changes a user makes from the tables before starting the transaction. You can't start a transaction on non-buffered DBFs at the init of a form and let the user work on the DBFs for say 5 minutes before they finally save and end their transaction, as that locks out other users. Not only from single records but from whole tables. So you need to combine the way of buffering of changes and of transactions to use them as they are intended to be used: Just starting the transaction before the first change you write out with TABLEUPDATE() and ending the transaction after the last TABELUPDATE(), if it takes multiple TABLEUPDATE()s for multiple tables.
Notice that even with a transaction not changing any DBF before you finally issue END TRANSACTION in your code, that does also not concentrate all writes to a single point in time. When finally END TRANSACTION is done, that just merges all queued-up file changes from that point on and has a duration that becomes longer with the number of changes you accumulated since BEGIN TRANSACTON. And it's still prone to failing if a power outage happens during that time. So in the end you can't prevent being prone to power outages with any coding, not even with transactions.
From the perspective of how much time is lost for the user needing to repeat his work no buffering and transactions mean less harm, as all changes are put into the tables right away, but then you also are more prone to corruption at each point you write. And in the end, a corrupt table that's not just having the simple defect of a mismatch in header record count and file size, but has a problem within a memo field or a whole section of the dbf overwritten with zero bytes, is an uglier problem than the time loss.
Chriss
-
1
- #5
Mike Lewis
Programmer
If the root of the problem is that the plug for the hub is occidentally pulled out of the power outlet, then a simple low-tech solution would be to stick a strip of coloured insulation tape over the plug.
I've done that myself in situations where a device must not be disconnected, and it has always worked well.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
I've done that myself in situations where a device must not be disconnected, and it has always worked well.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Just to recap the different situations you have at hand
1. LAN offline before you open data: No problem with the files, your app just can't work with no access, but they stay intact as they are.
2. LAN offline while you have a DBF open: No problem with the file, as writes will fail but the file stays intact as it was.
3. LAN gets offline just while you write: File corruption likely.
A notice on 1: It doesn't matter if that's at the start of your application or when you USE a table with the USE command in code or when a form having a data environment opens DBFs. They all fail to open the DBF or DBFs, but the file then of course stays as it is.
And 3 is the same problem as you have when a power outage turns off everything, not only the switch.
A UPS should mostly cover the server and the network hubs. ideally also all clients and client-side LAN devices like routers connecting to the server-side hubs, but you likely have too many places to introduce UPS devices to cover everything, so laptops are covering at least the clients themselves, there is nothing that could cover the whole LAN cable structure unless your LAN cabling is done from clients directly to the serverside hub and there are no intermediate local routers, like routers to which all clients of an office connect and that then connects to the server hub. Cabling wise it is nice to have cable ducts, but in themselves all cables are passive, they are powered by the clients and routers/switches hubs they are connected to. So the weak points in the LAN when it comes to the power supply are local routers/switches in the offices and it's questionable to avoid needing them by having longer cabling which all go from the serverside hub to clients without intermediate stations.
In larger LANs in multiple building companies, you surely will have at least one network hub in each building and could have those covered by UPS, they are handled like local server rooms and could indeed also host some local servers and other non-central but network-related devices like network printers and such things.
Anyway, you can only take care of the situation of power outages on all necessary stations and devices from clients to servers if all those devices are on UPS protection, not with software problem detections. Even if you get it to a point you can determine the status is okay very fast, you never know about the next moment. And when you write, you write, you can't protect the writing while you write. In that situation, the best you could do is monitor and notice the accidents, but that also becomes known to you by the errors that happen.
There is one more thing you can do in software: Not use DBFs, use a database server that has means like a transaction log that is like double book-keeping of any change. In such database systems, the power failure problems are taken care of by being able to recover to a healthy state with the transaction log. Transactions there become the norm, even if you don't program them as manual transactions, automatic transactions are done and more importantly logged to be repeatable.
And it is really recommended in your power supply situation to make use of a database server, not DBFs.
Chriss
1. LAN offline before you open data: No problem with the files, your app just can't work with no access, but they stay intact as they are.
2. LAN offline while you have a DBF open: No problem with the file, as writes will fail but the file stays intact as it was.
3. LAN gets offline just while you write: File corruption likely.
A notice on 1: It doesn't matter if that's at the start of your application or when you USE a table with the USE command in code or when a form having a data environment opens DBFs. They all fail to open the DBF or DBFs, but the file then of course stays as it is.
And 3 is the same problem as you have when a power outage turns off everything, not only the switch.
A UPS should mostly cover the server and the network hubs. ideally also all clients and client-side LAN devices like routers connecting to the server-side hubs, but you likely have too many places to introduce UPS devices to cover everything, so laptops are covering at least the clients themselves, there is nothing that could cover the whole LAN cable structure unless your LAN cabling is done from clients directly to the serverside hub and there are no intermediate local routers, like routers to which all clients of an office connect and that then connects to the server hub. Cabling wise it is nice to have cable ducts, but in themselves all cables are passive, they are powered by the clients and routers/switches hubs they are connected to. So the weak points in the LAN when it comes to the power supply are local routers/switches in the offices and it's questionable to avoid needing them by having longer cabling which all go from the serverside hub to clients without intermediate stations.
In larger LANs in multiple building companies, you surely will have at least one network hub in each building and could have those covered by UPS, they are handled like local server rooms and could indeed also host some local servers and other non-central but network-related devices like network printers and such things.
Anyway, you can only take care of the situation of power outages on all necessary stations and devices from clients to servers if all those devices are on UPS protection, not with software problem detections. Even if you get it to a point you can determine the status is okay very fast, you never know about the next moment. And when you write, you write, you can't protect the writing while you write. In that situation, the best you could do is monitor and notice the accidents, but that also becomes known to you by the errors that happen.
There is one more thing you can do in software: Not use DBFs, use a database server that has means like a transaction log that is like double book-keeping of any change. In such database systems, the power failure problems are taken care of by being able to recover to a healthy state with the transaction log. Transactions there become the norm, even if you don't program them as manual transactions, automatic transactions are done and more importantly logged to be repeatable.
And it is really recommended in your power supply situation to make use of a database server, not DBFs.
Chriss
Chris Miller
Programmer
Just to answer your questions more directly:
1. Is try catch ok to use?
No, a flaky network connection - not one that's clearly gone away by an unpowered router, won't trigger an error, but a file defect, which you then detecct next time, not this time. Puttin every UPDATE, REPLACE, INSERT, APPEND, etc. etc. into TRY CATCH you also don''t win enough control to handle all these errors, as there are some that might be due to LAN fails, but not all of them. You only overcomplicate anything you do and does not generally solve the problem.
2. Is it even worth doing testing LAN connection everytime users access to tables?
My answer above in short is no. I was concentrating on the aspect of whether a router without power causes a file defect, though, not about any error prevention. Let's look at this situation in more details: Just a router is without power and thus your LAN connection is gone. Both server and client still run, the client has buffered changed data, otherwise the discussion can end. If you don't use buffering, we talk about whether we can protect a single field change to not get lost because of an error crashing the application. It's relaly just not worth wondering about that. So assumed there are some changes lingering and would you know the LAN connection is lost in the mmoment, you could prevent an error, but still only wait for the LAN to come back. You would need to do some local storage of changes, or would need to keep the form up and open and in its state to not lose the changes. It's not practical.
It really boils down to solving this problem in a hardware solution than trying to work around flaky hardware situations (taking power outages into that realm, no matter how good the hardwae is in itself) with fault-tolerant software. Let's say it that way: If you would tell me to write software that can handle such situations, I'd higher my price to perhaps 10 times as much as writing a "just" decent software that relies on LAN to work. You save more by investing in a better hardware structure than by letting me write unfailable code. And "unfailable" could always only go as far as ensuring that even with a software crash the last state is recoverable. Even if managing that, it's not were you would usually pick up. As the duraiton of power outages is unknonwn, the employees that last worked may not be all available. It's likely when a user comes back next day his recovered local client situation is outdated, as others already cared about order fulfillment or such things.
Well, and then finally, as I already mentioned last in my previous post, a failsafe (in sense of data health) software system already exists in the form of database servers, and there are many to pick from that all based on transaction logging can recover to a healthy state and also prove their healthy state at start up by checking actual data against what the transaction log tells it should be.
It'll not cover the clients and all locally not yet stored changes, still. But as already said that's likely not even desirable. You already upgrade the quality of your situation significantly by using a SQL database server. It makes health issues to the data backend a very rare instance. Notice, not all problems are routed in power outages. Defects of DBFs and also of server data files can occur for other reasons, too. But they become really rare.
Let me put this in perspective of your frequency of power outages: The hard and software used in the moon landing mission was fault tolerant in several ways, but if they would have expected faults every few days, these tolerances wouldn't have been good enough to start the mission.
And so to power protect your server-side hardware, including the server-side hub with UPS is a must-have, it's no discussion point.
Chriss
1. Is try catch ok to use?
No, a flaky network connection - not one that's clearly gone away by an unpowered router, won't trigger an error, but a file defect, which you then detecct next time, not this time. Puttin every UPDATE, REPLACE, INSERT, APPEND, etc. etc. into TRY CATCH you also don''t win enough control to handle all these errors, as there are some that might be due to LAN fails, but not all of them. You only overcomplicate anything you do and does not generally solve the problem.
2. Is it even worth doing testing LAN connection everytime users access to tables?
My answer above in short is no. I was concentrating on the aspect of whether a router without power causes a file defect, though, not about any error prevention. Let's look at this situation in more details: Just a router is without power and thus your LAN connection is gone. Both server and client still run, the client has buffered changed data, otherwise the discussion can end. If you don't use buffering, we talk about whether we can protect a single field change to not get lost because of an error crashing the application. It's relaly just not worth wondering about that. So assumed there are some changes lingering and would you know the LAN connection is lost in the mmoment, you could prevent an error, but still only wait for the LAN to come back. You would need to do some local storage of changes, or would need to keep the form up and open and in its state to not lose the changes. It's not practical.
It really boils down to solving this problem in a hardware solution than trying to work around flaky hardware situations (taking power outages into that realm, no matter how good the hardwae is in itself) with fault-tolerant software. Let's say it that way: If you would tell me to write software that can handle such situations, I'd higher my price to perhaps 10 times as much as writing a "just" decent software that relies on LAN to work. You save more by investing in a better hardware structure than by letting me write unfailable code. And "unfailable" could always only go as far as ensuring that even with a software crash the last state is recoverable. Even if managing that, it's not were you would usually pick up. As the duraiton of power outages is unknonwn, the employees that last worked may not be all available. It's likely when a user comes back next day his recovered local client situation is outdated, as others already cared about order fulfillment or such things.
Well, and then finally, as I already mentioned last in my previous post, a failsafe (in sense of data health) software system already exists in the form of database servers, and there are many to pick from that all based on transaction logging can recover to a healthy state and also prove their healthy state at start up by checking actual data against what the transaction log tells it should be.
It'll not cover the clients and all locally not yet stored changes, still. But as already said that's likely not even desirable. You already upgrade the quality of your situation significantly by using a SQL database server. It makes health issues to the data backend a very rare instance. Notice, not all problems are routed in power outages. Defects of DBFs and also of server data files can occur for other reasons, too. But they become really rare.
Let me put this in perspective of your frequency of power outages: The hard and software used in the moon landing mission was fault tolerant in several ways, but if they would have expected faults every few days, these tolerances wouldn't have been good enough to start the mission.
And so to power protect your server-side hardware, including the server-side hub with UPS is a must-have, it's no discussion point.
Chriss
- Status
Similar threads
- Locked
- Question
- Locked
- Question