I am having a problem with disappearing data. The Software Company who developed this package has been paid for support services and has not been able to provide sufficient technical competence to solve the problem. They have basically washed their hands of the situation, leaving me to remedy the failures of their product.

I currently have 19 users on a Novell network running an Advanced Revelations version 3.111 application. Once a week I batch post receipts. These receipts have two fields, namely, "type" and "invoice" where the data intermittently disappears. Prior to batch posting these receipts, I run a SQL query showing data in these two fields. After the batch posting process, I run the same SQL query on the receipts that were posted and the two fields contain no data. This data disappears intermittently. One week my SQL reports before and after are identical, while other weeks I have disappearing data. It is interesting to note that there are absolutely no errors generated. Could I have an Advanced Revelation NLM problem?

Current Configuration:

Workstations: windows 98

Novell:

Novell Netware version 4.11

IPX 32-bit protocol for the Novell Netware client version 3.1

Frame type: ethernet_802.3

Advanced Revelation:

Advanced Revelations version 3.111

Advanced Revelations nlm version 1.5a

Application desktop Icon properties:

Both "allow screen saver" and "always suspend" are unchecked.

Command line: F:\Newarev\AREVNLM.BAT

AREVNLM.BAT:

F:

ECHO ON

Cd\Newarev

LHIPXTSR.EXE /P

AREV DEV /X

LHIPXTSR /U

Any help you can provide in the remedying this problem will be greatly appreciated. I think I need to find a company that can provide true technical support. Any suggestions?

Thank You,

Jorgeanna Clifton

Jorgeanna,

You configuration information looks pretty sound. I think most people would like to see you upgrade to AREV 3.12, but that shouldn't be the cause of your problems.

Most of us here are willing to help you in any way we can, but this is a step-by-step walk through method since we are corresponding via web posts. The usual reason for apparent missing data are corrupted indexes. Has this been looked into yet?

It's unlikely that this is an NLM problem, especially if all the appropriate checks are in place to make sure that the NLM is functioning correctly. The most import of these checks is the placement of REVPARAM files in all your data folders. Each REVPARAM file should have a line in it with "ServerOnly=1" (or something similar) in it. This will stop AREV from accessing your data tables if there is a problem with the NLM.

I agree, you need a company that will provide true technical support. Professionalism prevents me from advertising in this post. Therefore, allow me to direct you to the Developer Network link on this website. There you can find several companies who are willing to provide good and sound technical support for AREV.

One final question, is this application a custom written system or is it a marketed package? This could impact the level of support you will get. Most marketed packages don't provide source code. If the nature of your problem is in the way your application code is working then this may be trickier than if you had your own copy of the source code.

Let us know if and how we can help you more.

[email protected]

SRP Computer Solutions, Inc.

Do any of the files in question have relational indexes?

I've seen data in fields disappear before when there were problems with a relational index.

Type LISTINDEX filename to list the types of indexes on a file.

Dear Mr. Bakke,

I sure do appreciate you helping me in this matter!

I have created the REVPARAM file without an extension that is basically a one liner.

REVPARAM file:

ServerOnly=True

I have copied this file to every directory of that application that has linear hash files and that is basically every directory.

I have rebuilt every index in both the invoice and rcpt file.

After rebuilding all the indexes I decided to double check the nlm installation. The REVPARAM file had not been created so I created it.

I have not rebuilt indexes since creating the REVPARAM file. Should I go ahead and rebuild the indexes?

Thank You,

Jorgeanna

Jorgeanna,

It does not matter at what point you rebuilt your indexes. I presume, then, that you have no troubles accessing your system with the REVPARAM files in place. This is good news in the sense that you have eliminated one possible problem.

The indexes could still be corrupted (out of synch), but not repairable with a standard rebuild. Sometimes it is necessarily to "rebuild them from scratch" which is an involved process. It may also be necessarily to examine the field definitions (dictionary) for your database files to make sure they are defined correctly. If you want specifics on any of this then let us know and we'll proceed on this board. Otherwise, contact a competent consultant to review your system.

[email protected]

SRP Computer Solutions, Inc.

Janna,

Did you get your problem resolved? Please feel free to visit my web site to find out more about me. I'd be interested in speaking with you about your support issue.

Regards,

Eric Drews

Drews Enterprises

www.drews-ent.com

Often it IS the indexing to blame in some fashion in cases like this, but as often as not there's a problem in the application code itself (as Don says, whether you have access to this could be highly pertinent.)

FWIW, I've seen an effect like this in a couple of different systems which used the somewhat-suspect Date*Time*Station architecture to provide unique keys. They sort of worked ok in the "olden days" on slower PCs, but suffered data loss by overwriting when cranked up to write more than one row per second on faster kit. This tended to be most pronounced during bulk auditing or "batch" posting operations (which is why it came to mind when I read of your problem.)

Cameron

The file uses a Btree index. Although the file is Btree indexed, the two particular fields with disappearing data are not indexed. I put a call into the software company yesterday to verify the contents of the dictionary and they called today only to tell me they're not sure when they can get back to me. Great support! When this problem is resolved, I'm definitely looking for a more competent support company!! I have since re-built all Btree indexes in the file. I won't know until tomorrow if this will remedy the problem. Since these two fields are not indexed, does it necessarily imply that I could still have an indexing problem?

View this thread on the forum...