For the first time in 24 years some users are getting the scrolling "Record is not available" in FPW 2.5. This error is extremely annoying because it can't be trapped by an error handler, and it has no error number. I can only rely on users to tell me it's happening, and have no way to time stamp it. The program is running on Terminal Services with Windows Server 2008 as the file server.
There are 4 terminal services servers, 1 file server, and approximately 40 users. I have been told this happens on 2 unrelated programs each hosted on the same server, although this is not verified. This makes me think this may not be a software issue, hut instead a hardware issue. This started when 5 new employees started. 5 more simultaneous users, but these users are only using one of the programs. It only happens for a few minutes then clears itself. It happens maybe 2 times a day for 5-10 minutes and everyone has to wait. I've gone through google and the leafe archives and found some hints. I think this is a hardware issue, where some rogue task is taking down the file server's or terminal server's performance. The hardware guy seems to think it's a software issue, even though 2 separate, distinct programs are having issues and they don't have any interaction between them.
1. I recreated the indexes from scratch, not just reindex. 2. The line code that triggers this
set century on replace gemdebto.dmmemo with gemdebto.dmmemo+chr(13)+chr(13)+chr(10)+"Notes:"+dtoc(date())+' '+time()+' '+"Computer:"+padr(memuser,15,' ')+' '+memnotes flush
if rlock() replace debt.lastworked with date(), debt.nxt_con_dt with date()+7 flush endif
I know I can do that in one line with one replace command, and one flush.
Are Flushes necessary on a modern setup like this? Set autosave is on, should it be set off? Could that be causing too much network traffic? I can't believe that it would with only 40 people.
Any ideas?
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---