Hello,
 
I am helping to convert from OWPW accounting to DBA accounting. All manufacturing is currently run on DBA Classic. We intend to start the accounting change by tracking sales orders/accounts receivable with DBA in parallel with OWPW. We plan to work on inventory at a later point in time.
 
Problem:
When posting invoices with SO-G, the data transfers to the current General Ledger batch, but the system locks up after the post is made (the freeze occurs with the SO-G Post Invoice screen open). An error window opens stating "Invalid Pointer Operation."
 
Recent changes made to the system (chronological):
1) In accounting General Ledger Defaults, turned off COGS, PO, Inventory Adjustment, WO transactions, and use of item class GLs (all fields set to "N"). COGS had been posting to the clearing account.
2)Cleared existing accounting data with UT-K-A.
3) Fixed binary 0's with UT-K-I.
 
Another thread indicates that invalid pointer operation errors may be corrected by re-indexing files.
 
Are there any particular files we should re-index with UT-C to attempt to fix this error?
 
Thanks,
Matt
Denbro Plastics

Dave--
 
Thanks for your reply. I did back-up and re-index the specified files. The problem has not been fixed.
 
We are running DBA version 2002.3. Since the software has functioned as intended from installation until now, I am reluctant to patch or update.  
 
My plan is to continue backing-up and re-indexing additional files;  DBA help lists the files associated with the various modules (AP/AR/BM/etc.).  Unfortunately, I am not sure which specific files are accessed by the SO-G command.
 
Regards,
Matt
Denbro Plastics

Thank you Lynn--
 
I ran the SO-G operation in DBA with the pervasive monitor utility running. I attempted to re-index the indicated files with the UT-C command; all of them went through except for the BKSYMSTR.B file. For this file, an error window appeared on the DBA screen and the re-index command did not proceed.  
 
Is it likely that we have a corrupted BKSYMSTR.B file (or possibly a bad pointer in one of the fields), and if so what is the best way to repair the file?
 
Regards,
Matt
Denbro Plastics

Dave--
I re-indexed the "BKSYMSTR.B" file, and a number of new problems developed.  
 
After creating a new test company,  the test company was selected with change company in the file menu in order to re-index the BKSYMSTR file. The file extension for the files re-indexed up to this point was ".B". The pervasive monitor function showed ".B" files active.
 
After re-indexing the "BKSYMSTR.B" from within the test company with UT-C, the file menu was accessed to change back to the main company. Now, 3 companies appeared in the change company pulldown: the newly created test company [73], "Denbro Plastics Co []", and a 3rd company called "License Expired See AD-A [99]."  
 
Prior to creation of the test company and the "BKSYMSTR.B" re-index, there was no option to change company; DBA only had one company record available. "License Expired See AD-A [99]" appeared after the "BKSYMSTR.B" re-index.  
 
After selecting "Denbro Plastics Co," all of the sales records were current, and posting with SO-G generated an "invalid pointer error" once again.  
 
The files activated by SO-G were re-indexed once again, as indicated with the pervasive monitor function. When SO-G ran after this re-index, an error message stated: "Access violation at address 00658C68 in module 'TP5WDBA.EXE.' Read of address FFFFFFFF."
 
An invoice was voided, and an attempt to post the credit memo generated the error message:"Access violation at address 00402053 in module 'TP5WDBA.EXE.' Read of address 01202020."
 
After a restart, and a second attempt to post the credit memo, an error read "Invalid pointer operation." However, this did post as the sales order was accessible again.
 
Next, we turned off accounting in order to see whether the initial "Invalid Pointer Operation" and the new errors were already present but only made visible by turning on DBA accounting. All DBA Accounting was turned off: GL, AP, and AR. A test sales order was created, released, and the invoice printed.  
 
The SO-G command now produced the error: "Access violation at address 00401E0D in module 'TP5WDBA.EXE'. Write of address 01202020."
 
Additional details:
1) After selecting the "License Expired See AD-A [99]" company, the pervasive monitor function shows the ".B" files active. These files are also active for the current company named "Denbro Plastics Co []".
 
2) The FILELOC, ERRMSG, and USERS files (which do not allow re-indexing with UT-C) are located in the Dbamfg/ directory while the other active files are located in Dbamfg/default/ directory.
 
3) The site-license was turned over to Denbro Plastics when the original company changed owners. The data in the "License Expired See AD-A [99]" company appears to be the data from the company with the original site-license.
 
Is this a problem with two company records now accessing the same default files?
 

Dave--
 
You were correct.  I made a mistake using the Pervasive monitor function; the [99] company was using its own set of *.B99 files.
 
After running the DDCHECK, backing up the files, and following the actions indicated on the error report, the SO-G problem appears to be resolved. Specifically: 1) the BKGLX file did not agree with the dictionary definition, and 2) there were a number of files with record length discrepencies. The BKGLX file was corrected by running the "UPDATE" program from the windows taskbar. The record length discrepencies were corrected by running the UT-A UPDFILE program. There have not been any error messages since this file maintenance was performed on 10/10/06.
 
Thanks,
Matt
Denbro Plastics