Everyone said, "and your procedural code is entirely compatible between OI and AREV."

Well, there might be a FEW differences. Like, command names. Or command functionality. Today I discovered the DETACH_VOLUME command which compliments DETACH_TABLE in OI, only the detach_table documentation does not reference detach_volume. (In AREV, DETACHTABLE_SUB did both jobs.)

Then I have been reading the Revelation white paper about .DBT files. The routines which support these files are DEFINE_DATABASE, RDKUPDATEDBT, LOAD_SYSPROGDBT, and SWAP_DATABASE. Of these commands, only DEFINE_DATABASE is documented. At the least, I need the documentation for SWAP_DATABASE too. I am looking to replace the AREV functions of Set_Attach_Image and Use_Attach_Image.

Has anyone looked at the SYSTABLES table definition in Table Builder? The definition which shows fields 1, 3, and 5? Hmm. If the database is not defined in the documentation or in the application, how can developers use it?

Gerald

Richard,

I appreciate your B-right attitude.

Gerald

Everyone said, "and your procedural code is entirely compatible between OI and AREV."

Well, there might be a FEW differences. Like, command names. Or command functionality. Today I discovered the DETACH_VOLUME command which compliments DETACH_TABLE in OI, only the detach_table documentation does not reference detach_volume. (In AREV, DETACHTABLE_SUB did both jobs.)

Then I have been reading the Revelation white paper about .DBT files. The routines which support these files are DEFINE_DATABASE, RDKUPDATEDBT, LOAD_SYSPROGDBT, and SWAP_DATABASE. Of these commands, only DEFINE_DATABASE is documented. At the least, I need the documentation for SWAP_DATABASE too. I am looking to replace the AREV functions of Set_Attach_Image and Use_Attach_Image.

Has anyone looked at the SYSTABLES table definition in Table Builder? The definition which shows fields 1, 3, and 5? Hmm. If the database is not defined in the documentation or in the application, how can developers use it?

Gerald

Gerald,

As previously mentioned, it would be helpful for EVERYONE if you can flick your observations of short-commings on documentation thru to Ira, who will attend to it. That way we all get to benefit. He, poor guy, gets little constructive feedback or support from users.

Secondly, I believe that in the past (why do I need to differentiate) the practice was NOT to document certain routines BECAUSE once documented, there would entail a explicit commitment to proctect that operational behaviour. In other words, development and enhancement of key system functions would then be hampered. You will see that same logic in any development environment, particularly Microsoft.

Please dont get me wrong, I'm not trying to throw a wet blanket over your bitching about documentation and code performance. Rather its great to get your energetic input and critical observation and challenging the status quo. My point is I would like that useful contribution to find its way into betterment of the RevSoft environment.

Richard Bright

Richard,

Thank you for continuing to respond on the subject of documentation. While you have said that Ira is the point person for documentation issues, this is NOT Revelation Software's current position as far as I know. I would like to have a more direct mechanism for input to Revelation Software's product improvement processes. It would avoid having to post inadequacy notices in the discussion groups, which just appears to be "bitching."

However, Revelation Software does not publish e-mail addresses for individual employees, nor do they have addresses which seem appropriate for submitting input on product improvement. I have sent private correspondence to Revelation's staff, only to have the responses posted to the discussion groups. This may be distasteful, but it appears to be the accepted process for receiving and providing input with Revelation Software.

Hopefully others will recognize that you and I are not complaining; our dialog is just a commentary on mechanisms for improvement. I know that Revelation Software is trying their best every day to correct the problems that years of neglect have caused. I personally feel that the biggest challenge facing the company today is replacing a culture of elitism with a structure which welcomes newcomers to the OI community. Revelation Software's success will be determined by how well they accomplish this.

Gerald

Oh, I was (de)famed as a born optimist - by one Marc Radley - plus I like the occasional free T-shirt in the mail, if not a cheque.

Well… Microsoft gives me T-shirts (any number - which size to wear today) AND cheques. YES, I am totally corruptable and can be bought off. Please corrupt me. Just dont try and change my opinions.

Richard Bright

BrightIdeas New Zealand

View this thread on the forum...