Internal data structures corrupted

[BruceN]

HELP !!! We have a beta site running our program locally and remotely via terminal services on a 2003 server.

Everything has gone VERY smooth for the last several days... hundreds of invoices at main store, dozens at remote with no problem.

This morning we had an error at remote store:

oError:args :
-> VALTYPE: B VALUE: {||trim(inheader->h_storeid) == trim(m_stwo[77]) .and. substr(inheader->h_custid,1,1) <> '|'}
oError:canDefault : Y
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Internal data structures corrupted
oError:filename :
oError:genCode : 41
oError:operation : DbSetFilter
oError:osCode : 0
oError:severity : 2
oError:subCode : 5
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0

We then tried another invoice at remote store and all was well. the next invoice done on that same machine (thru terminal services) had same error.

in between those 2 errors, about half a dozen invoices were done without issue at main store (obviously in the same data files).

Any thoughts.. this is beyond my ability. I don;t know where to startl ooking.

thanks

[Auge_Ohr]

oError:operation : DbSetFilter

Any thoughts.. this is beyond my ability. I don;t know where to startl ooking.

try SET OPTIMIZE OFF

[BruceN]

I put that in main with the other sets. lets see if it works. so far we've tried 5 or 6 invoices with no problems. Lets hope it continues to work.

Why would it work flawlessly for a few dyas, then start to act up?

THANKS!!!!

[BruceN]

It happened again!!! I don't have a clue on what to do.

It happens (so far) only at the remote store (which logs into the server via terminal services). The remote store does only a dozen or 2 invoices a day a most. Everything worked fine for a few days, then we had 2 invoices with that 'internal data structures corrupted' error. I made the 'set optimize off' change as suggested. Everything worked fine for a few days, then saturday it happened once again. No problem since then.

Always on the filter on the same file. It happens when writing an invoice (to the invoice header file). That isn't even the biggest file written to (the invoice line item detail file is significantly larger).

In processing an invoice there are numerous writes to different files that happen consecutively... this is the last of them. Could the system be 'going to fast' and somehow that causes the problem? Would a sleep(10) before and after that write possibly help?

I'm stuck and have a customer that is as frustrated as I am.

Any help will be greatly appreciated.

[Auge_Ohr]

It happened again!!! I don't have a clue on what to do.

did you try SET SMARTFILTER OFF and SET RUSHMORE OFF too ?

[BruceN]

no... but i will now! will that slow things down any?

[skiman]

Hi,

I never use dbsetfilter, but this kind of error is probably a corrupt index. Do you have a reindexing routine?

You are sure this is a 2003 server and not a 2008 server?

Otherwise look at www.alaska-software.com/smb2. Yes Jimmy, I do know you are against disabling SMB2, but it solves index problems.

[BruceN]

yes it is 2003 server. and it isnt a corrupt index. other users have done numerous invoices writing to the same files (and insexes), reading from them, and using the same filter.. without problems. and it only happens very sporatically to the remote 2 terminals logged in thru terminal services.

if you don't use filters (this is the first time i tried them), what do you do?

we need to filter out records based on a new field recently added (storeid) in numerous files. changing the indexes would be a nightmare... as files are opened,indexes set, indexes changed in probably 500 places, or more, in the code.

by having a filter in a fcn and calling that fcn from the open file fcn i was able to limit the records without major code changes. if you have a better way i'm all ears!!!

thanks

[Auge_Ohr]

yes it is 2003 server.

did you use "ops-locking" Settings ?

and it only happens very sporatically to the remote 2 terminals logged in thru terminal services.

hm ... so they run "local" on Server.

did your Application "detect" using Terminal Service ... perhaps you have some "delay" ...

if you don't use filters (this is the first time i tried them), what do you do?

we need to filter out records based on a new field recently added (storeid) in numerous files. changing the indexes would be a nightmare... as files are opened,indexes set, indexes changed in probably 500 places, or more, in the code.

by having a filter in a fcn and calling that fcn from the open file fcn i was able to limit the records without major code changes. if you have a better way i'm all ears!!!

i have rewritten all my "Filter" to SCOPE which is much quicker

[BruceN]

what are 'op locks settings' where do you set them, what should they be?

Not sure what you mean by 'detect'. Logging in thru TS starts our app and they log into it as normal running in a virtual desktop on the server.

As for scopes.. perhaps my understanding of them is wrong. I was under the impression that they had to be based on the controlling index. For example, index by date and scope to jan 1, 2010 to Dec 31, 2010.

We need to filter basically by 2 parameters at different times. Both scenarios are used in multiple files (customer, invoice detail, invoice header, PO detail, PO header, etc)

1) by the first character of the CUSTID field (substr(custid,1,1) = {or not equalto} '|' (pipe symbol)
this is done regardless of the actual index on the files which could be date, invoice number, custid, or numerous other things.

2) by STOREID, again regardless of the index.

frequently a file is opened with one controling index and changed to another one (not sure how that would work with SCOPEd data)

Is my understanding of a scope wrong? Would they work for me?

thanks