tbl.unmark.range()

[Tom Cone Jr]

I'm using vers. 4.03, build 230 on a windows 98SE system.

tbl.unmark_range()

This high-level utility appears to alter the current index without warning. When run, it seems to change the current index to record_number order, regardless of which other index may have been in effect when it was invoked.

Try this with a table that has at least one production index.

tbl = table.open("yourdbf")
tbl.index_primary_put("yourindextag")
tbl.fetch_first()
trace.writeln("some value from the current record"+" is first before unmarking")
tbl.fetch_last()
trace.writeln("some value from the current record"+" is last before unmarking")

tbl.unmark_range() 'unmark all recs in current range

tbl.fetch_first()
trace.writeln("some value from the current record"+" is first after unmarking")
tbl.fetch_last()
trace.writeln("some value from the current record"+" is last after unmarking")

tbl.close()



When I do this the paired before and after values are different because the table
is ordered by record number after the unmarking is completed.


If this is working as designed, it's a bit counter-intuitive and probably needs to be documented in the xbasic ref. manual.


I had quite a bit of difficulty this evening because I was trying to mark records in a particular way and began my script by unmarking everything. Unbeknownst to me this caused the sort order of the records to be different since the table reverted to record number order... which caused my marking exercise to behave incorrectly. Naturally I checked everything... and I do mean everything... before finally finding out what was happening.


-- tom

[Peter.Wayne]

RE: tbl.unmark.range()

In your example, you did not create a query or range first,so the unmark_range() would act on the default query, which is
record-number-order. What happens if you set a query first? Does tabl.unmark_range() still reset the order to record numberorder, or does it keep the current query?

[Tom Cone Jr]

RE: tbl.unmark.range()

Thanks. Let me clarify.


I did not run a query, but I did specify a particular order for the table, with the index_primary_put("indextagname") statement. I assumed this would remain primary even after the unmark operation. Instead, the unmark operation seems to do an 'index_primary_put("") replacing the indextagname with a null string, thereby making the new 'primary' display order to be in record number order. This I would argue is counter-intuitive. Why should unmarking all records change the display order for the table?



Are you saying that I should run a query to select all records first? The ref. manual indicates that the function will work against the current query or range... I've always assumed that that 'Show All' is a range, indeed I think of it as the 'default' range. Maybe this is where I've been confused....???



I guess what I meant to say is that I was surprised to learn that the tbl.unmark_range() function changes the ordering arrangements for the table. I did not mean to say that it changes the number or identity of the records included in the current query.


-- tom

[Tom Cone Jr]

RE: tbl.unmark.range()

Further testing indicates that if I run a query against the table and choose a filter that selects all records, the query remains in effect after unmark_range() has finished its work.


Guess I'll just have to file this one away. Is this too broad a statement:


The default query and the default range for any table is always record number order. This includes all records in the order in which they were entered into the table. Setting the primary index for the same table to a production index does not change the default query or the default range.


-- tom