If you change the dict field number of a field that is being related to, will just an index rebuild fix it all up, or, would you have to delete and recreate.

I don't know the answer to your question. But, I believe that the source code for the indexing of a table is made available if you create a row in the !file named !!, that is two exclamation marks. When you add an index to that table the next time I believe !! will have the source. Then you can examine it to see if it contains the position number of the indexed F-type columns.

Let us know.

I'm also interested in why you would change the field number of a dictionary (you imply that this table is in production mode)?

Dave Harmacek

Harmacek Database Systems

Dave,

It is development mode, but being testing as if production by client.

When a Quote becomes a Job, I copy the whole record and change the data values in a couple of fields as I do.

I have been making changes to the Quote and Job dicts and suddenly realised they are out of sync for a 'copy all fields and they will match', so what I decided I should do is that any new dict items on the Job file should be starting from 100, will will allow any further maintenance on Quotes to still cause no problems.

But, I still need to move the existing new job dicts up a notch to 100+ and this includes multivalue relational index fields.

As this is basically in the field I have to do the change programmatically.

I have a test copy that I check upgrades with, so I can use that to test each method.

I will look at the ! records and see what I can dig up.

Thanks for the help Mr PX.

Well, after all that OI has pulled me up on it when changing the field no in the dict.

1. I changed the field no for a B/Tree field and got msg that index needs to be rebuilt, but let me carry on.

2. Changed the field no for the related index and I got pulled up and NOT allowed to continue, with message saying I had to remove the relational index first.

So there!

Well, after all that OI has pulled me up on it when changing the field no in the dict.

1. I changed the field no for a B/Tree field and got msg that index needs to be rebuilt, but let me carry on.

2. Changed the field no for the related index and I got pulled up and NOT allowed to continue, with message saying I had to remove the relational index first.

So there!

Yeah, you can probably get away with modifying dict records on btrees, since DICT.MFS is pretty good at managing that, but the system really doesn't like when you manipulate relational indexes. You could probably do it, if you changed the !FILE records first, then probably the dest then source dicts, but you're much better off playing ball with the system and doing it through the proper tools.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

Thanks, I played ball and all is fine , using the rbasic functions in a pre/post upgrade.

View this thread on the Works forum...