Hi All, Thanks for the reply and suddenly missing in action. Fell sick and my colleague took over to check and solved it already but we still have no idea what the actual problem. Basically this email just an update of what we did to test.
We could not find any issue with this server including the NIC. Database health is good. Could not find any fault with the customer's network either. Connection testing: The connection actually was not idle, I was corrected by my colleague on this. We created an Invoice transaction with one item. running about 10-20 select statement and wait for reply from the server and then perform an update to the database. This takes about 1-2 seconds. For test purpose, we created an Invoice with almost 10,000 items. What happened is, first item run about 10-20 select, wait for reply, then second item run another set of 10-20 select, wait for reply....until the end, whereby an update is perform to the database. Time took for the first part of select is about 10-20 mins depending numbers item we are testing. Update will take less than 10 seconds. The connection is lost middle of the first part, whereby the server do longer reply. After further checking, we found out this server was calling another computer in the network to run some script/batch files. Since the server in our office, could not locate that computer and working fine, we suspected that might be the cause. A quick call to the customer's IT support told it was for running system backups and not that keen to let us know more. Without much go to on another than suspecting it might be the script files causing the problem, we decided to format and setup the server to our liking. Which actually just the normal standard vanilla Windows, installed in Firebird and our programs. Put it back to the customer site, no problem...their IT support setup back the script files and all the other programs, no problem as well. So far the customer no longer have any complains on this and they considered the case to be closed. And since the problem no longer can be reproduced, our side don't have much to go on as well. Anyway, thanks everyone for your help and opinions. Thanks and regards, John --- In [email protected], "anchovies" <anchovies00@...> wrote: > > > We have seen very similar problems in large fb dbs. After much network > troubleshooting, it wasn't network issue. More like "corrupted" db. A > backup/restore of that db with issue would fix it. You might want to give it > a try. > > rgds, > john > > --- In [email protected], Steve Wiser <steve@> wrote: > > > > Check to make sure the NIC on the server is not auto-negotiating the wrong > > speed or duplex > > > > -steve > > > > -- > > Steve Wiser > > President > > Specialized Business Software > > 6325 Cochran Road, Unit 1 > > Solon, OH 44139 > > > > www.specializedbusinesssoftware.com > > www.docunym.com > > (440) 542-9145 - fax (440) 542-9143 > > Toll Free: (866) 328-4936 > > > > > > > > > > On Thu, Oct 20, 2011 at 7:46 AM, Norman Dunbar <Norman@>wrote: > > > > > ** > > > > > > > > > John, > > > > > > > > > On 20/10/11 12:18, gwc8182 wrote: > > > > > > > Took the client's server back for testing and unsurprisingly the problem > > > could not be reproduced anymore at my office. > > > Ok, there's a clue there. The network at the customer site. Well, the > > > infrastructure at the customer site. > > > > > > > > > > Going to perform few test on the server before deciding to reformat the > > > server. > > > Reformat the server is a tad drastic. Sounds like a Microsoft Certified > > > Engineer type thing! <duck and runs> ;-) > > > > > > There is, I'd bet, a network configuration somewhere that's causing this. > > > > > > Have you tried, as was suggested, leaving a couple of ssh sessions (or > > > something else that connects and then sits idle) open, but idle, to see > > > if they disconnect as well? > > > > > > I'd be willing to bet that a reformat of the server will not solve the > > > problem unless you reinstall Windows (?) and reconfigure it to not kill > > > dead connections. > > > > > > The links I gave in my previous reply might give you a clue as to where > > > to look for the setting. > > > > > > > > > Cheers, > > > Norm. > > > > > > -- > > > Norman Dunbar > > > Dunbar IT Consultants Ltd > > > > > > Registered address: > > > Thorpe House > > > 61 Richardshaw Lane > > > Pudsey > > > West Yorkshire > > > United Kingdom > > > LS28 7EL > > > > > > Company Number: 05132767 > > > > > > > > > > > > > > > This message and any files transmitted with it may contain information > > > that > > > is privileged, confidential, and exempt from disclosure under applicable > > > law. They are intended solely for the use of the intended recipient. If > > > you are not the intended recipient, distributing, copying, disclosing, or > > > reliance on the contents of this communication is strictly prohibited. If > > > this has reached you in error, kindly destroy this message and notify the > > > sender immediately. Thank you for your assistance. > > > > > > We attempt to sweep harmful content (e.g. viruses) from e-mail and > > > attachments, however we cannot guarantee their safety and can accept no > > > liability for any resulting damage. The recipient is responsible to > > > verify > > > the safety of this message and any attachments before accepting them. > > > > > > > > > [Non-text portions of this message have been removed] > > >
