I clear a table programmatically with clearfile, and afterwards I check how many rows there are with a programmatic Get.RecCount or with Database Manager's LH Table Info. The table is cleared all right but the row count is not changed.

It seems I have to run clearfile twice before the count is reset to 0.

If I clearfile once and write more rows to the table, the count just increases. E.g if I have 100 rows, do one clearfile, and add an additional 50 rows, the count becomes 150.

Sounds like I did some trivial mistake, but what?

OI 3.61, single user developer.

- Oystein -

The row count is stored in the LH table header. It's incremented and decremented during a write and delete. It's refreshed during a full file pass. For whatever reason, it's not zeroed during a clearfile.

Make of it what you will.

[email protected]

Sprezzatura Group

Ask a stupid question department:

If a table is cleared, and you just cleared it,

why would you want to count the records?

Eric

(Always del *.* at least five times, so they stay deleted)

Aaron,

The row count is stored in the LH table header. It's incremented and decremented during a write and delete. It's refreshed during a full file pass.

You mean if I do a full file pass after the clearfile, the row count will become zero? What I do straight after the clearfile is to update (i.e, clear) all the table's indexes with an Update_Index call. Doesn't Update_Index do a full file pass?

For whatever reason, it's not zeroed during a clearfile. Make of it what you will.

If I was paranoid I'd assume somebody got something against me…

- Oystein -

Sounds like a "feature" to me - with or without legs.

AREV resets the record count to 0, by the way. I suppose you caould do a select (not rbasic, but RLIST) on the table after clearing it.

Don

Update indexes doesn't/shouldn't do anything with the file. It just goes through the tokens in the 0 record and performs the actions required there. One would assume the ALLIDS token is there, so the index would rebuild since it's empty, which would then run through the file, but I'll lay you emus to gnus that the code does a Basic+ simple select for a ALL.IDS token which bypasses the row count update. Only RLIST( 'SELECT…'s) do that hence no update.

You could set the ForceCount parameter to True$ which will force a rescan and update the header straight away.

[email protected]

Sprezzatura Group

Aaron,

You could set the ForceCount parameter to True$ which will force a rescan and update the header straight away.

I've tried to force the count, but it makes no difference.

- Oystein -

There were 2 methods for doing this, one did a full scan with an incremental counter, the other made an RTP57 call. Don't remember which one OI uses. Try doing the RTP57 call and see what number you end up with.

[email protected]

Sprezzatura Group

Eric

If a table is cleared, and you just cleared it, why would you want to count the records?

Ever gone back to check if you really turned off that stove? Just creating the programmatic equivalent of that. Programs with a human touch if you like.

(Always del *.* at least five times, so they stay deleted)

- Oystein -

Aaron,

You lost me.

- Oystein -

Well FWIW just tried

   Declare function Get.RecCount

   Open "LOG" To V Then

      A=Get.RecCount(v, "", "")

      ClearFile V Then

         B=Get.RecCount(v, "", "")

         Debug

      End

   End

using SLists handy dandy TCL EVAL statement (rather than the upgraded industry standard Pick enquiry language we otherwise emulate ) and A=8 B=0. Anything else strange about the file? Sizelock perhaps? In use by another user so Group 0 lock set?

[email protected]

Sprezzatura Group

World Leaders in all things RevSoft

Don, Aaron,

I'll try an Rlist call tomorrow. (I'm not at work now.) Shouldn't take long to execute on an empty file.

(Perhaps it's so quick I could even do it twice…)

I'll tell you what I need the row count for: In my app I have a query window where the user can select and copy rows from a table S ("S" for "Source") to a table T ("T" for "Target"). The user can repeat the process as many times as he likes, accumulating rows in T.

He may also come back in a later session and continue the work. When the window opens I'd like it to tell the user how many rows are in T already. Since I don't want to spend the user's time waiting for an explicit count I thought I'd just use the row count. Naive me.

- Oystein -

Today's listening suggestion: Mr Scruff: Keep it Unreal (Ninja Tune)

Expect the unexpected and other Mr Scruff blurb

[email protected]

Sprezzatura Group

World Leaders in all things RevSoft

Andrew,

Get.RecCount(v, "", "") … … Anything else strange about the file? Sizelock perhaps? In use by another user so Group 0 lock set?

No other user but I'll check the rest. Tomorrow, when I'm back at work.

Btw - the syntax I use is

Get.RecCount(v, Flag, false$)

or

Get.RecCount(v, Flag, true$)

- Oystein -

Same results using your syntax … and why aren't you in bed?

[email protected]

Sprezzatura Group

World Leaders in all things RevSoft

Andrew,

why aren't you in bed?

Probably was by the time you wrote that.

Now back at work it's even more bizarre than I thought. Let's say I write 3 rows. The row count becomes 3. Then I clearfile. A couple of times, until Get.CountRow becomes zero. Then I write another 4 rows. Whereupon the row count has become 7!

I rebuild or update indexes straight after the clearfile, and for a while I thought the problem had something to do with that. It seemed the presence or absence of an Update_Index call makes a difference to my function. But not to yours.

But can it have something to do with me opening the table more than once? All takes place in one window, but there are several handlers that all open the table. First of all there is a Select Output Table list box with a handler that gets and display the initial row count after the user has chosen the target table. Then there is a Do It button that performs the copy process itself. Then there is a Clear Table button that does a clearfile. Etc. All these open the table anew.

Of course I could let the first handler save the table handle in a common variable so I didn't have to open it more than once. But I didn't bother.

I don't know if it's relevant, but I don't have user events, but a commuter function with all the programming for the window. You know what I mean - a function with lots of handlers in a big case-sentence. I use the same variable everywhere for the table handle.

- Oystein -

View this thread on the forum...