|
Post by billgrantford on May 18, 2021 16:46:35 GMT 1
ARAGO creates local files ...NDX DBF and so on to run local. Once the editing of the files is completed the edited data is sent back to the server. When doing a search in the database (DBF) a INDEX (NDX) is created however only the TEMP.NDX is created then vDos started task goes dead. the folders are C:\INVOICE and C:\INVOICE\INVOICE I've checked permissions on related folders all access is given still the only files being generated is the index that stalled at 1k.
Complete correction to the above Post:
To sum this up since there was a break in testing. When searching a name against a database, the search stalls and does not complete.
What appears to happening is the search on the database file, which is large, the search stalls out. This test was conducted with "QUICKIDLE=OFF" , I've tested this in various forms on the name search. Example by last name, full name the results are the same as to stall and not complete.
Everything else functions excellent, this our last hurdle to implement vDOS...
|
|
|
Post by billgrantford on May 18, 2021 16:47:52 GMT 1
We are in the testing phase before we purchase...will that make a difference ?
|
|
|
Post by Jos on May 18, 2021 18:10:23 GMT 1
Doesn’t ring a bell. You could start vDos with the log option (….\vDos.exe /log). Perhaps the generated vDos.log will reveal what’s going wrong.
The only difference between registered or not, for if that applies, is the nag once every 3 hours and a notice every 16th page when using the internal print processor.
Jos
|
|
|
Post by billgrantford on May 18, 2021 20:59:59 GMT 1
I was working with the log file, I'm still confirming that the coding on ARAGO is suitable for the file structure. I'll be back lol
|
|
|
Post by emendelson on May 19, 2021 0:17:54 GMT 1
Jos, Arago seems to be a dBase compiler last sold in 1992. I never heard of it until today, but there are some references to it in old magazines.
|
|
|
Post by billgrantford on May 20, 2021 17:43:12 GMT 1
So our software ARAGO creates TEMP files for the DBF's it uses. All editing is done on the local machine, when we complete the editing the data is then transferred back to the database that resides on the servers. I have observed this activity, but not all the required TEMP files are being generated on the local machine. Also I see that almost all the temp files are deleted when the task is completed, I'm not sure that this is an issue. Files like PRTTEMP are not generated and lock the main PARTPRINT.DBF, I'm assuming by these actions VDos is locking the file, which it should generate a PRTTEMP work file on the local machine. All this being said the time to response is extremely slow to a non-responsive state. How does vDos handle temp files?
|
|
|
Post by billgrantford on May 20, 2021 17:52:45 GMT 1
Jos, Arago seems to be a dBase compiler last sold in 1992. I never heard of it until today, but there are some references to it in old magazines.
Yes its a dead product, it ran for 2 years and died....Our owner built the entire dealership interface in ARAGO (16 bit) He has no desire to change it either. 8u
|
|
|
Post by Jos on May 20, 2021 18:27:30 GMT 1
TEMP files are not special to vDos. How should vDos at all determine a file is temporary?
vDos also doesn’t delete, nor lock (exclusively open) files if the DOS program doesn’t request that.
You could start vDos with the log option (….vDos.exe /log). The generated log file will probably at least show why some TEMP files are not created.
Jos
|
|
|
Post by billgrantford on May 28, 2021 15:36:33 GMT 1
Update...the last application executable with an issue. GOTCK.EXE which access our INVOICE Database through various menu options, fails when searching the database by customer name. The Database name is PRTPRINT at 70,500 kb, the local index file is created, the PRTPRINT is locked during the search. While watching my local Task Manager the vDOS task is working away then falls off to idle state. I will say that once in a while the search does complete retuning the results, however 99% of the time the task has to be ended via Task Manager. I have ran down the security route and that is fine....I've ran down the resource allocation route to a dead end. What do you think?
|
|
|
Post by Jos on May 28, 2021 16:39:51 GMT 1
I would say vDos goes to idle too soon, initiated by the program excessively polling the keyboard while still performing that search?
You could first add this line to config.txt: IDLELOW = 25000
If that doesn’t help: QUICKIDLE = OFF
Jos
|
|
|
Post by billgrantford on May 28, 2021 19:49:50 GMT 1
Thank you testing now: These task ran longer however still went to IDLE with QUICKIDLE=OFF
LOG vDos 2021.05.01 SetCodePage 437 C: => (Local) c:\INVOICE\ E: => (Remote) \\SVR-08\E\ G: => (Remote) \\SVR-08\gdrive\ F: => (Remote) \\SVR-08\fdrive\
0.03 Execute: GOTICK.EXE() 0.05 Int 3F => 1799:0198 Redirect INT 24 ignored, won't be further logged Int 0 => 01A5:307E Int 23 => 0BE7:0951 Int 1B => 0BE7:096E Int 3F => 0906:1A4C XMS unhandled call 10 Int 2F unhandled call 1687 Int 8 => 1F3B:40E2 Int 2F unhandled call 1687 Record locking verified for DOS E: 0.06 FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.MDX(18) FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.WDX(18) FindFirst failed: C:\ARAGO.WDX(18) 0.08 Int 9 => 1F3B:4092 0.09 FindFirst failed: F:\INVOICE\LOG.WDX(18) FindFirst failed: C:\LOG.WDX(18) FindFirst failed: C:\LOG.WDX(18) FindFirst failed: F:\INVOICE\LOG.WDX(18) FindFirst failed: C:\LOG.WDX(18) FindFirst failed: C:\LOG.WDX(18) FindFirst failed: F:\INVOICE\LOG.WDX(18) 1.03 Delayed logging, set w/o DOS call: Int 22 => original 10.07 FindFirst failed: F:\INVOICE\PARTPRNT.WDX(18) FindFirst failed: C:\PARTPRNT.WDX(18) FindFirst failed: C:\INVOICE\PARTPRNT.WDX(18) FindFirst failed: C:\PARTPRNT.WDX(18) FindFirst failed: F:\INVOICE\PARTPRNT.WDX(18) FindFirst failed: C:\PARTPRNT.WDX(18) FindFirst failed: C:\INVOICE\PARTPRNT.WDX(18) FindFirst failed: C:\PARTPRNT.WDX(18) FindFirst failed: F:\INVOICE\PARTPRNT.WDX(18) Record locking verified for DOS F: Int 21 unhandled call C702
|
|
|
Post by billgrantford on May 28, 2021 20:20:00 GMT 1
I did some research on my own and it looks like an optional feature was missing....Hebrew Supplemental Fonts may be the culprit. Testing now.
|
|
|
Post by billgrantford on Jul 13, 2021 15:54:25 GMT 1
All fixed!!!! The answer is ADMIN=ON and IDLELOW=25000....Thank you for your time and support! We will be contributing shortly.
Mike
|
|