We have a very simple program which counts the number of records in a file:

    SELECT Fle

    Rec.Count='

    Loop

        readnext else EOF=Y'

    while EOF=N'

        rec.count += 1

    repeat

if @reccount ne Rec.Count then

 =error =

end

At some sites the number of records read is different to the number selected (Rec.Count ne @RECOUNT).

There is also an attempt to read records with a key of:

• *

We think is the Appication ID and User ID.

is the ID of other PCs logged in.

If 2 PCs logged in then there are 2 invalid Keys returned.

When the EOF is set to 'Y', @reccount has been found to be changed to the number of invalid keys (* etc), eg 1 or 2.

We have one site with 2 PCs side by side.

One PC has this problem and the other does not, even when logged in under the same ID. The Technicians are adamant that both are set up the same way, but we dont think so.

It only happens to larger files. Eg those with over 5,000 records.

But the number of records changes each time the program is run.

Smaller files have no problem.

We are sure that it is related to settings somewhere, Windows Firewall, Anti-Virus software, Admin Rights etc. It could be that Terminal Services has an effect.

The big concern is that reports do not select all the records but give the impression that they do.

Suggestions would be appreciated.

Hi Robin,

It looks like your SELECT statement is activating a Latent (unresolved) list, but @reccount is only reliable for a resolved active list. Only use @reccount if @list_active=3, or @reduction_done is true.

You could use the get.reccount() function to get a total recount count.

Eg, rec.count=get.reccount( fileVar, status, forceCount). If forceCount is 1, then the function will physically count all the records (rather than just get the LH count in the file header).

HTH, M@

[img]http://www.vernonsystems.com/images/logo_main_ani.gif[/img]

"But the number of records changes each time the program is run."

See this thread for some info that might shed some light on this…

http://www.revelation.com/o4wtrs/oecgi3.exe/O4W_DOMINO_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&KEY=F4B505ED442A7D60852573C8006E8748&KEY1=F4B505ED442A7D60852573C8006E8748

"There is also an attempt to read records with a key of:

"

Look at this topic. It seems to be very similar to what your problem is.

http://www.revelation.com/o4wtrs/oecgi3.exe/O4W_DOMINO_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&KEY=6C7E47AD65146B5D8525762B001DF9C8&KEY1=6C7E47AD65146B5D8525762B001DF9C8

Look at this topic. It seems to be very similar to what your problem is.

Not surprising since the originator of that thread is also Robin Tinker!

[email protected]

SRP Computer Solutions, Inc.

Yes and there wasn't a resolution offered in the thread.

Robin, could you by any chance be trying to check the number of records in the SYSLOGINS table? If so doesn't that change dynamically as users come and go?

John

Thanks to all.

This program has been running for many years.

It reads all the records in all the files in a system to check the files are all valid. The problem is arising in files like the Debtors and the Creditors files.

We have a standard routine which clears outstanding SELECT lists

CLEARSELECT

* Clears all cursors

For counter=0 To 8

ClearSelect counter

Next counter

@reccount ='

I come back to the problem that there are 2 PCs side by side, one works and one does not. We can select all the records in each of say 20 files. One PC reads all the records in each file, the other reads only some records when there are more than nn records in the file.

nn changes each time the program is run.

Eg the bad PC selects 1000 records and reads only 300 one time and 400 another time. There are also the rogue keys coming in.

We have copyied the system onto the local drive of the bad PC, pulled the plug to the network and still get the problem running from the local drive.

The Tech is adamant that the good and bad PCs are setup the same way but I can not see that this is correct.

OI 8.0.1

Robin,

I am beginning to wonder if the "bad" PC has bad memory.

[email protected]

SRP Computer Solutions, Inc.

Robin,

A couple of things. As mentioned in the linked posts, you really will need to set sizelock before issuing a Basic+ select. Why do you need to do this? Because it's possible that during a select another station will resize the file while you are processing. This means that records/rows you haven't hit yet could be moved into groups you've already processed.

What does that mean? Suppose you have a file with 100 groups. You're processing group 40, reading in the keys. Another process comes in and causes the file to resize. Some keys from group 90 are moved into group 22. You've already processed group 22. These records will be skipped.

The reverse is true as well. A record from group 10 could be moved to group 80, and you'll process that one twice.

When setting the sizelock, you need to set it to something above 2 because you want the file to remain fixed, not just not shrink.

This sizelock logic needs to wrap the entire process, so that's select and readnext, not just select. On a latent select, the logic is processed during the readnext, so you're never really finished until every keys is known to be processed.

Now, while it is true that all indexed selects are resolved, even Basic+ ones, it's safer to always wrap Basic+ selects with sizelock commands.

What's interesting here is that the errors always occur on a single machine. I generally operate on the theory that code is code, so on any given machine, a set of opcodes that says X+=1 or loops through an LH table group by group, returning all keys will work identically (baring the sizelock issue). Allowing for sizelock, it would be just as likely to have errors on one workstation as another.

So, intuitively this points to a workstation difference, but before we jump to that conclusion, let's rethink about what we know and make some small guesswork on my behalf.

One could reword your "large file"/"small file" into static and dynamic, since smaller files generally tend to remain fixed, while larger files are constantly being manipulated. This manipulation could cause resizing. Remember, it's not just adding and deleting rows that cause resizing, writing changed rows can cause resizing as well, even if the file doesn't change size, since the system doesn't always know it can fit back to where it was.

So, your large files could be resizing even if you think they aren't.

We're back to the workstation differences again, this time keeping in mind that we're pretty sure there's some resizing going on in the background.

From my perspective as software, hardware people don't recognize small changes as changes or differences, since they won't matter, so it's not important. Well, yes, you're on slightly different versions of NETX, but all the readme says is that this fixes an problem with IPX port clearing, and you're not using IPX, so that doesn't matter.

Unfortunately, you have to verify all this stuff yourself, so check everything, down to patches, though it is true these days there's less variation in net config than there was back in the good old days when you had to generate your own netx.com files.

One thing you haven't mentioned (or I missed) was the LH network driver and server version. As mention in our Universal Driver article, you shouldn't be using the UD drivers without the LH service. If you are using the All Networks Driver, then you have to contend with what's being cached on the various bits of the "workflow", so from PC to routers to server.

My guess is that the errant workstation could have some additional caching and could be pulling information from cache, and not the disk, which is why it's always off.

So, questions for you:

1) What driver and service are you running?

2) Does it make a difference if you change the order of execution, so run machine B before machine A?

3) Can you generate the error on any other machine?

4) If there are indexes involved, check with Revelation if you need the Index Reducer Patch.

5) Check if there's an MFS on the file, since there could be some programmatic limitation of the result list based on user ID or station ID.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

FWIW - I'm not certain if this is the cause, but I can relate that we have seen similar behavior when the sort path directory was set to a network directory and became shared by more than one user.

The issue manifested itself when running RList reports that would produce inconsistent results. It seems similar in that both are readnext'ing and would appear to exhaust the list prematurely.

I believe there are several threads on how to dynamically set the sort path using Set_Env(). We modified our system to use the Windows %TEMP% directory, which should reside on the local PC (or would be a unique folder for each user if in a Terminal Services environment). You may want to give that a try.

HTH,

Chip

I have also seen strange results when the sort path is set to something invalid. For instance setting it to c:\temp when there isn't a folder or the user has no rights to the folder, will cause this behavior. OI will not fail the select, just return bad results. Although, I should say I am not checking the value of status() upon return from Rlist. Perhaps the errors are set but we never check them. IMHO, Rlist should really do more than just set a flag. It should dispaly a message and terminate the whole process…

John

View this thread on the Works forum...