Does anyone know if it is possible to ascertain the internal name of a Rev file without Revmedia data. Ie in the case of a corrupted Revmedia file.

From my investigations so far I would assume that the answer is no !!

Simon.

Rebus HR Ltd

Well you could work on the assumption that the dictionary file will be the next number down and see if that gives any clues. Or if there is an attach image you could search that for clues.

The Sprezzatura Group

World Leaders in all things RevSoft

Simon

Do you mean that SYSTABLES is corrupted too?

I can usually get the dos name/file number out of that.

First I try to read something out of the file that I want to know the dos name for, any record eg %RECORDS% if nothing else. Then I look up the corresponding record in SYSTABLES and usually the dos file name is in that.

I wrote a program to look select all the table records in SYSTABLES, look up any record in the table then look up/read the table record in SYSTABLES and extract the related dos file names out of that.

I am sure this isn't the official way but I find it fairly useful.

Scott.

Janet,

I don't know how it is different, but records in my Systables do not include the dos file name.

However, even if they did, a lot of the time our system holds backup tables that aren't attached permanently and so this wouldn't work anyway.

For all readers - is there a setting that causes OI to hold the Rev filename in Systables records ??

Simon

Simon,

Don't know. But there's one thing that if implemented would have avoided the problem altogether: Let the data files have plain names derived from the table names, like CUSTOMER.LK + CUSTOMER.OV, ORDER.LK + ORDER.OV, etc, instead of cryptic names like REV52388.LK + REV52388.OV. This is possible. I think I'll do that in my new app.

- Oystein -

Oystein ..

Beware of naming DOS files like CUSTOMER.LK / .OV if you're using Indexing. My recollection is that some of the low-level routines in indexing only will look at REVnnnnnn (ignoring the extensions, etc.). This goes back to early Pick days, I think. Many of the low level routines were coded back in REV C-F days with all you had was ROSnnnnnn.xxx (Link files used .LNK). Most of this stuff remained through early AREV days (and a lot of it is still there - META for one). The other issue is that once a REVnnnnn.nn has been created and an index put on it, you're in a big pickle unless you're extremely handy with REVMEDIA. Oh well, that's enough of this stuff for now.

Don Miller

C3 Inc.

Don,

Thanks. I'll sit tight and see if there are any comments from the ones who set me on the idea.

- Oystein -

Doesn't file locking also use the file names to create the lock table? By using 'natural' names for the files you increase the chance of having non-unique native file names across volumes.

Wasn't this one of the reasons why Cosmos/RTI changed the intial Volume REVxxxx to begin with a semi-random number rather than REV10000 as version 1.0 would always do?

Simon

SYSTABLES records won't have the dos name in until you try to read a record in the table that you want to find out the name of.

EG if you have a table called FRUIT, to find out its rev name:

Open a record out of the FRUIT table eg open the APPLE record in syseditor. I don't think it matters if the APPLE record doesn't actually exist in the FRUIT table so long as you attempt the read, then (and only then) does the whole thing get resolved in the SYSTABLES file. Then you open the FRUIT record in the SYSTABLES table to find out what the dos file refs are.

I figured that it was one specific table you wanted to know the REV name for, then this would be ok.

I wrote a program to go through and get everything. And no, you aren't going to find out what is what without attaching the volumes. You could write a program to do that too, attach and detach. My code would need a bit of modification to work with someone else's system but I don't mind posting it or emailing it if it would help. It uses OIPI to report, it has some proprietary stuff for messages and gas gauge which can be replaced or commented out.

Scott

Janet,

That explains why you had the DOS name - as soon as the file is opened the SysTables record will hold that data.

I have actually written a routine to rebuild the RevMedia, having perused a routine supplied to me from Don Miller (free plug !!) that has successfully done what I wanted. I am working to extend it to be fully functional for all occasions of Revmedia corruption.

The problem is that if the tables exist but are not attached and the Revmedia is corrupted enough that you cant Readnext thru' the Ids, then the Tablename is 'Unknown', although it could be possible to determine the Dict.Unknown table as the 'next door' number, but this can't be taken for granted.

I just wanted to know, hoping RevTech / WinWin would have responded, if there was some sort of indicator, however obscure, within the header of the table of working out what the table name is, Data flag, Dict flag, ! flag etc to minimise the amount of detective work afterwards to work out what the table was in the first place.

Simon

Rebus HR

Simon-

There aren't that many clues, but here are a couple:

The !files have a !TABLENAME records in them, where in field 1 the first field (based on an asterisk) of the first subvalue is the name of the !table.

The dictionary to datafile numbering scheme has already been discussed here.

Most of the time we've needed to do this in the past- only about 8 or 10 times ever- we've been able to recreate the file based upon user information about data in the file or dictionary.

Sorry I don't have a better answer-

Mike

Thanks Mike,

I thought that would be the case, I was just hoping that there might be something I hadn't seen in there.

Simon

View this thread on the forum...