Wireless FAT Client in XE/ERP8 Oracle


Well Known Member
We recently migrated a group of users to an office which has wireless connectivity exclusively. They are using FAT clients and all has not worked smoothly, they are experiencing constant disconnects from the Oracle database. We have checked some of our firewall settings and it does not appear to be the issue.

Has anyone else out there implemented a similar scenario and found a solution or setting that would preserve our connectivity to the database.

Do you have any debug logs of the disconnects? If so, what do they indicate? Do they contain any timeouts?

We have come across a similar issue recently, though probably different to yours, but there may be something in our experience that can help you.

There has been a change (effecting the test/development installation only) to a new firewall that results in connections to the database and the ldap server being timed out by the new firewall without sending messages to the JDE server, the ldap server or the database server (which the current production firewall does) and there is no option to change this behaviour. This situation is compounded by the fact that the JDE software assumes the connections are still open (without doing a "heartbeat" check) and JDE waits for a timeout. The result is that signing on to JDE sometimes requires 2 or 3 attempts and each attempt can take 5 minutes or more. Granted, in a production system, because of the much higher level of activity, it would not be as much of an issue, but it still would be an unacceptable situation. Setting the timeout on the ldap server to be less than that on the firewall has helped, but the same action with the database or database server does not seem to work. One work around that we have considered is to run a short UBE on the JDE Scheduler every 2 hours to prevent the new firewall from timing out the connections.
The errors vary, from end of communication , to selects and forcing a reconnect , we have experienced time out issues in the past with out wired in users,
but those occur within several minutes to hours and while annoying is not a show stopper, and simply require a retry to the database, the wireless an experience it traveling
from one application to another. Incidentally we are also having issues with other products that use oracle databases and rely on continuous connections.

Some of the log messages.

3480/4336 Thu Dec 11 09:05:58 2014 dbperfrq.c386

3480/4336 Thu Dec 11 09:05:58 2014 dbperfrq.c393
OCI0000179 - Error - ORA-03113: end-of-file on communication channel

3480/4336 Thu Dec 11 09:05:58 2014 jdb_drvm.c988
JDB9900401 - Failed to execute db request

3480/4336 Thu Dec 11 09:05:58 2014 JTP_CM.C1881
JDB9900255 - Database connection to Control Tables - Prod has been lost.

3480/4336 Thu Dec 11 09:06:11 2014 JTP_CM.C1399
JDB9900256 - Database connection to Control Tables - Prod has been re-established.

Check if there is some sort of "keep alive" setting on both the PC's wireless ethernet and your router.

Well - your network guys are going to have fun with this...

Are your machines losing connection and reconnecting - and you just aren't catching it?

There's a known "Turn off password protected sharing" bug - on a lot of wifi adapter / wifi router connections. Turn the setting off and see if that resolves anything. Go to Network and Sharing Center and click on “Change Advanced sharing settings", then under "All Networks" (at least for W8.1).... The problem here is that the setting will randomly drop the connection... it appears to be specific to each network, for example - connections to my home, plane, airport wifi had issues, work had no issues. Setting it Off - the wifi has no issues anywhere anymore.

Not sure that will resolve the issue - it might make the connection via wifi a bit more stable.

Just a quick update, it appears to be a firewall setting, on the other application where we were also having issues, we set up a different port number to the database and it is now functioning, Once they figure it out we will resume wireless testing, in the meantime we have moved them back to wired connections.