I have created a relational index in OI the is set to AR (Asending Right Just)

When related records are added, the keys are adding as thought the sort is BOT.

Works ok in Arev3.

The dict record shows *AR at the end on field 23

IS this a known problem - Can anyone tell me theirs are proven to be working or not working.

Attn REVSOFT

We need the listindex menu in OI to show the relational settings.

Barry

On playing around further, there appears to have been a bug in the RENAME_VOLUME routine, that was posted in the Online Discussion , that still left an old account name in one of the records in the !Filename file.

BUT. I stiil think taht OI does not cleanup remove and add of relational indexes correctly.

AND

The should be a neater way of seeing what makes up a relational index.

Barry,

On playing around further, there appears to have been a bug in the RENAME_VOLUME routine, that was posted in the Online Discussion , that still left an old account name in one of the records in the !Filename file.

Then I hope the posted version isn't the final one. I've already started using your routine. (Yes, I've seen the correction with saving the database.) I haven't used it for changing account names yet, just volume names. But I hope it's safe for changing volume names.

BUT. I stiil think taht OI does not cleanup remove and add of relational indexes correctly. AND The should be a neater way of seeing what makes up a relational index.

I agree on both points.

But do you really need relational indexes? Some very experienced developers once suggested I stay away from relational indexes. The idea of relational indexes is great but OI's implementation of such is too unreliable. And one problem that you didn't mention is they can get full, since they are stored in fields in data rows, which have a limit on their size. In my apps I use relational indexes only for limited purposes - for a few static tables with not too many rows and relations.

The alternative is to do a search at runtime. Will that work for you? Computers are much faster today than when relational indexes were invented.

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

oystein.reigem@hit.uib.no

Home tel/fax: +47 56 14 06 11.

Today's listening suggestion: Photek: Infinity.

Oystein/Barry-

The posted code is being revisited.

For the 3.7.4 release there is a new command 'LIST_INDEX_DETAILED' which shows Tablename, Column Name, Index Type (eg Btree, Xref). For relationals it shows the related info like this Products-]Invoices-]AR, showing that this field in this column if related to the Products Table, the Invoices File, and is Ascending Right Justified.

Mike Ruane

Great…

Umm

]]For the 3.7.4 release there is……and?

]]LIST_INDEX_DETAILED

Dont forget to put it in the "Help" at the same time.

Remember, right now. The database manager requires more extensive changes.

Other changes include:

Enhanced HTML generation for the Form Designer

XML generation/examples

Widened SCAN_REP Window

more…

Dont forget to put it in the "Help" at the same time.

Will the online Help be updated? I don't believe it until I see it. There are tons of omissions and inaccuracies and errors already.

- Oystein -

Oy-

Can you tell me the specific Errors- I'll get as much fixed as I can.

Thanks-

Mike

Mike,

I don't think there are as many plain errors as inaccuracies, omissions and similar. And I don't keep a comprehensive record of neither. I'd have to scan the discussions and all my notes to find everything I've come across. And I haven't got time for that.

But here is a random and mixed collection - not just plain errors. I hope others will follow with their contributions:

BRFHELP:

There is an erroneous keyword "COUNTROWS" in the OpenList documentation. If one tries e.g

RUN RLIST "COUNTROWS ",1

one gets

"COUNTROWS is an invalid statement type."

"COUNT", on the other hand, works, but is not docced. To be more precise it's the following simple syntax that works:

RUN RLIST "COUNT ", 1

If one includes search criteria:

RUN RLIST "COUNT ", 1

it doesn't work. The result seemes to be like what a

RUN RLIST "LIST ", 1

would produce.

The OpenList documentation makes reference to controlling printer output through PDISK.

The docs say about the Mod function that it is calculated by the following formula:

Mod(X,Y)=X - (Int(X/Y) * Y)

This formula is mathematically correct and works for all integers - also when X is negative. But at least in OI 3.61 the Mod function fails miserably on negative numbers, so it's a lie that the Mod function calculates according to that formula.

The "TABLE" property: According to the online help you can do

associatedtable=Get_Property(objectname, "TABLE")

The help text doesn't say that the object has to be a field control. I admit that developers who know that windows can be bound to more than one table, will suspect it only works for field controls. But not everybody who read the docs knows that. Also, a developer who knows about multi-table windows might assume it works, but that an array of table names is returned.

The help texts on the Function statement and the Subroutine statement state correctly that functions must have parameters but subroutines needn't. But the syntax definitions say the opposite.

The programming example for OSWrite uses OSBWrite instead of OSWrite.

The programming examples with OS(B)Write should have a call to Flush. Flushing is necessary to free the file so other programs can use it.

The help text on the Btree.Extract function doesn't mention you can call it several times to get back lists ] 64K.

The DETACH_VOLUME system routine isn't docced.

OR_VIEW and OR_PRTF aren't docced.

Arithmetic operators aren't docced, except the multi-value ones. Don't scoff. (It isn't obvious to everybody that the exponentiation operator is "**".)

Constants syntax isn't docced, I think. I especially remember hunting much for the hex syntax.

Cannot find anything on legal characters in variable names. E.g function names are mentioned but not variable names as far as I can see.

I don't think the docs say where to find all the error codes and messages.

How and when to do error checking isn't properly explained. There ought to be a general article about error checking and handling. Also the articles on each statement and SSP should contain specific information about error checking and handling. All programming examples should contain error checking and handling, when relevant.

There are many ways to do a search in OI. There ought to be a general article on the subject.

Revelation Reporter online help:

According to others: There is an error in the online documentation. The /REP command (which specifies if the report is located in the Repository or not) is incorrect. The command should be /RE=1 for reports stored within the repository, and /RE=0 (zero) for reports stored outside the Repository.

- Oystein -

Thanks.

I also know of an error in the ARRAY property, plus a couple of others.

I'll let you know what happens- watch this space!

Mike,

Great!

(Btw - I might be off the Works list for a while. Some trivial problem with the payment for the renewal of my subscription.)

- Oystein -

Hi there.

I have seen many complaints regarding Relational indexes, but I find it can be a very useful tool. In fact I have some apps which rely very heavily on them. Why sould I want to search anything if I can have the system do it?

I really think it's time for Revelation to review Rel indexes' implementation and give it a second hand. I've been loyal to Arev (and now OI) for all the developer's tools it has to offer and I believe every tool deserves further development. That is what I would expect as a customer. No less.

Regards,

Ilde.

Mike,

Another omission in BRFHELP:

Rlist callback is not properly documented. There's nothing on how many arguments the callback function should have, and what they contain. Also nothing on what the callback function should return.

- Oystein -

IMHO, you're not likely to get it. This has been around for a looooong time with numerous complaints over the years. If they were going to tackle it, they would have a long time ago. I gave up on AREV's relational indexing years ago and wrote my own.

Don Miller

C3 Inc.

Don,

…wrote my own.

It doesn't by any chance circumvent the 64K limit….?

- Oystein -

Oystein .. sorry about that..64K reigns supreme for this one. If I need to get around that, I use B-Tree and then glue the pieces together. Remember, browse lists have a limit too. The reason to write my own Relational Index routine was a bugaboo in zero-filled keys in the detail records. This was part of a Bill-Of-Materials app which needed to keep track of "Where Used" and "Uses" relationships such that a change in cost/price at any level could ripple up or down as necessary. The AREV version was just too unreliable for my taste.

Don Miller

C3 Inc.

Don,

I think there are 3 possible ways a relational indexing system could behave when it comes to that 64K row limit:

- Be able to handle it. If it stored relational indexing data in a different way, e.g, like ordinary indexes, it could get past the limit.

- Not be able to handle it, and jam or crash. Like OI's relational indexing does.

- Not be able to handle it, but stay alive.

For some purposes I'd be quite satisfied with the latter.

What I mean with staying alive is something that just gave up and said "Sorry" if there were two many keys. Often a relational isn't very useful when there are many related rows. There could be some upper limit on relational indexing data, say 40K, so there'd always be plenty of room for ordinary data fields. When the volume of keys threatened to go beyond 40K the system bailed out gracefully. It would still keep track of the number of keys, but not the keys themselves. If the number of keys went below a certain lower limit (set depending on the average or maximum size of keys) relational indexing would kick in again and rebuild the indexes.

Enough daydreaming.

- Oystein -

Hi Don and Oy.

So it means it's time to roll sleeves again and…

Regards,

Ilde.

View this thread on the Works forum...