Just received RTI's little note telling me what I can't do with a runtime licence!

Did anybody else get one ??

How can you possibly "maintain" any installed application

*simply* if you can't:

- Update the Repository (when adding/deleting entities) via an update process

- Fix corrupted indexes (without the *right/ability* to use Create_index, Delete_Index etc)

Whilst I understand the necessity to limit Compilation/Changing of Forms/Event Executables etc - these other restrictions are simply

*draconian* to say the least!!!

Seems that the "unlimited" runtime licences line hides are more sinister "sting in the tail" ??

Comments please

-

Tony,

Welcome to the hot button topic for many of us lately. I gather you don't have access to the Advisory board because there is a long thread dedicated to this topic up there.

Rather than banter on this subject once again let me offer you a couple of suggestions for getting the most out of your deployed runtime systems.

First, you can always use the RDKInstall function to maintain your systems. This gives you the ability to modify dictionaries, indexes, as well as system components.

Second, RTI just released a single user version of their DRSDP (Developer Ready Server Deployment Pack) so the client can now administrate the database much the same way the owner of a developer version of AREV could. The big difference is that you have to swap the runtime engine for the developer engine therefore locking everybody out while administrative tasks are carried on. Nevertheless, we feel its a good step forward for providing a more economical solution with providing runtimes direct maintenance capabilities.

Hope this helps,

[email protected]

SRP Computer Solutions

Thanks for your thoughts Don

I *think* I have access to the advisory board so I'll have a look.

Surely RDKInstall is a loooong winded way of executing a

Create_Index program call ??

I am aware of the Development Ready Licence but not the cost.

Again isn't this also an expensive way to (re)build an index as we all know how stable they can be :)

Just seems to me to be a money grab - first Works program to get version updates (which I can justify) now Developer Versions where a Runtime used to be and would suffice 99.9% of the time !!

What next - CPI IDs and automatic software licence verification ??

oops someones already doing that aren't they ?!?! :)

Don

I checked.

I don't have access to the advisory board

How does one *get* access to the advisory board???

Regards

Tony

Tony-

Revelation has not changed what can and cannot be done with an OpenInsight Runtime license. The mailing you received was in response to various conversations and threads on the web that seem to indicate there has been some confusion about what capabilities are available with a Runtime license. The point of this mailing was simply to clarify those capabilities.

The OpenInsight for Workgroups Runtime licenses you to run a locked-down application. The word "unlimited" refers to the license to distribute single-user runtime applications and has no bearing on the functionality of that application.

Let me reiterate again that Revelation has not changed the Runtime license to prohibit behaviour that was previously available; the restrictions and capabilities of the OpenInsight for Workgroups Runtime license have remained consistent. Any questions about licensing should always be immediatedly directed to Revelation Software for clarification.

Jennifer:

OK - Will this work, since it's not covered in the recent mailing?

We will be offering an OI-based upgrade to our AREV core app (which is in AREV 2.12 and not 3.1x). Will the SETALIAS allow for reading and re-writing the data portion of the existing tables programatically assuming that the new tables are all pre-defined, including indexes, etc.? That is:

SETIALIAS

OPEN ALIAS_TABLE

OPEN NEW_TABLE

SELECT ALIAS_TABLE

READNEXT ALIAS_TABLE

READ ALIAS_TABLE,@ID

WRITE NEW_TABLE,@ID

.. etc

New users of the APP will start from scratch. I have a large number of installed sites who are anxious to migrate. They are small businesses with strict budgetary issues since they are accountable to both Federal and State governmental agencies.

Don Miller

Scott

Thanks for you post.

The point I'm trying to make is *why* should/must something so intrinsically necessary (and one of the major advantages OI/AREV) namely indexes, be *so hard to do* (legally) when a simple polocy adjustment would simplify the process.

My understanding (and I'll confirm it with Jennifer Scheer) is that

a) I'm not *allowed* to "create/delete" indexes in a Runtime

*and*

b) If I try the program will not let me anyway!

My discussions with developers here in Australia lead me to believe RTI is *not* impressing anybody with this policy.

It *will* be a *hot* topic at our Developer Conference next week!!

Regards

Tony

Jennifer

Thanks for your comments.

I understand that RTI are not "moving the goal posts during the game", *but* would it be right to sell somebody a car with 5-speed gear box and then tell them they *can't* (read not allowed to) use the fifth gear or have it serviced (unless they can buy a licence to use the fifth gear & or upgrade to the top of the range model which is really the only practical choice).

Fom a developers (salesman's) viewpoint, that's going to price the car *out of the market* and so he may as well go and sell Amway.

Now if the customer is told that in the beginning *before* they buy the car *and* *fully understand* the effect that's going to have on the saleability and maintainability of their car - then caveat emptor.

Sure it's possible to get it serviced but only by "driving across the country" or "taking out a loan" - Porsche or Ferrari come to mind.

We are talking software development here - not cars. Cars are commonplace and fairly easy to understand the effect of the restrictions. Software development is *so* nebulous that someone "joining" the RTI community is unlikely to understand the effect of such restriction nor are they likely to be told by RTI or its reps so they "go in blindfolded".

That's what this runtime restriction amounts to in relation to indexing and updating of the repository entries (namely adding functionality to an existing application).

Am I making my point ?

If you'd like to discuss this my number is

+612 98048800 Sydney Aust

Tony -

I disagree with your analogy but rather than trading analogies all day long, let me make the following points:

1. To reiterate, we have not changed our licensing policies and practices regarding the Runtime licenses.

2. Revelation Software does not sell its technology and products, but rather licenses their use within a set of specified terms and conditions. These terms and conditions are described in the Software License Agreement. The Software License Agreement may not be amended or altered verbally. The Software License Agreement may not amended or altered unilaterally.

3. It is the Software License Agreement, not technical feasibility, that determines how the licensed software may or may not be used. The ability to utilize the software in a certain manner does not necessarily mean that it is licensed to be used in such a manner.

4. Every customer who wishes to develop and deploy an OpenInsight application must read the Software License Agreement and agree to its terms. Anyone who does not understand the terms, or who requires further clarification should contact Revelation Software directly before agreeing to the terms of the license (and using the software).

5. As stated above, The Software License Agreement is THE document that informs the customer in advance how the software may or may not be used. Following is an excerpt from the OpenInsight License Agreement pertaining to Runtime Deployment:

Runtime license provides one end user use of an OpenInsight application; however, it does not allow the user to change or modify the application. Applications are delivered using a Runtime license when the application is fixed, and cannot be modified. The Runtime license specifically prohibits the ability to create or modify database components (files, dictionaries, indexes), as well as any application component (such as reports, forms, programs, etc).

The OpenInsight License Agreement is online in the Product Info section of our web site - click here to link to it.

Tony,

I must say I agree with you. I can understand runtime licenses not allowing changes to be made to an application, even so small changes as adding a new index. But I can *not* understand why runtime users are not allowed to fix broken indexes. And indexes do break. Also on single user systems.

- Oystein -

Fine Jennifer

Let's be constructive then.

There is obviously a *need* for this functionality (indexes etc).

Is the *only* way one can obtain said limited functionality is through a full development licence ?? at say Aus$2000+ ?? at *every* site I install ??

Don Bakke noted some serious activity on the Advisory Board on this topic. Is this a "closed shop" or can others be privy to the discussions ?

I'm just looking for the most economical answer to a *real* issue.

I look forward to your response.

Tony

Oystein

My point exactly! Maybe I'm just banging my head against a brick wall??

or maybe its the Aussie in me that is searching for the *reasonable* middle ground?

I must admit that I'm starting to feel that money has become the *primary* focus of RTI, especially if I take recent *offers* on face value.

I mean the Works Program *was* a fair deal this year (I paid Aus$895), but at US$1590 (Aus$2500) I don't think it will be next year.

Maybe I'll have to look elsewhere for *my* money generator. Maybe that's the objective ??!?

Oh well ! Back to my brick wall ….:(

There is obviously a *need* for this functionality (indexes etc). Is the *only* way one can obtain said limited functionality is through a full development licence ?? at say Aus$2000+ ?? at *every* site I install ?? … I'm just looking for the most economical answer to a *real* issue.

The way to implement database administration functionality on a runtime system (at a minimum) is to apply a single-user DRDSP onto the system. Your emphasis of "every site" indicates that you have a large number of installed sites that require this functionality. You should work with your sales representative (in your case David Goddard), who can help you develop a volume purchase agreement to provide you with the most economical program for getting the properly licensed functionality to your customers.

Don Bakke noted some serious activity on the Advisory Board on this topic. Is this a "closed shop" or can others be privy to the discussions ?

We set up the OpenInsight Advisory Board as a smaller forum with a sub-group of WORKS subscribers for specific input on a variety of issues. This is not an open forum, and the Advisory Board discussions are not currently available to non-Board members. I encourage you to continue to use this forum to discuss any issues or questions that you have (and of course, you can always contact us directly as well).

Jenifer,

I think I must be dim. I can understand a runtime license not allowing changes to be made to an application, even so small changes as adding a new index. But I can *not* understand why RTI have decided runtime users are not allowed to fix broken indexes. Indexes do break, you know.

- Oystein -

Jennifer,

single-user DRDSP

Btw - what is a single-user DRDSP? Product Info doesn't mention it.

- Oystein -

Tony,

As far as I know .. OI is the only environment which has these type of limitations. The idea that you can't create new tables (storage for monthly processes etc) or add fields/indexes is simply RTI's way of squeezing the turnip.

But this is how they have always been since RTI .. In all Pick-Pick-aLikes and Oracle, MsSql, Informix etc the client to a database can create new tables (depending on access rights). ONLY RTI keeps you from creating these tables easily .. without tricks and the possiblity of litigation.

I really wish that these limitations would be lifted.

[email protected] onmouseover=window.status=an advocate for open data systems!;return(true)"

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

The single-user DRSDP is a new deployment product we have introduced to make it more economical for developers to deploy development-ready capabilities to a single user (either by adding just one Dev-Ready user to a runtime system or by incrementally adding a single user to an entire Dev-Ready system.

Here are some informational links:

THE SINGLE-USER DRSDP: Using a Development-Ready OpenInsight System in conjunction with a Runtime System

The introductory promotion in North America

Sorry it took so long to respond to your question but I wanted to make sure that I gave you the correct information.

The answer to your scenario is: it depends. If the table is a data table, then you are ok. You cannot, however, do this with a dictionary table. (The problem is with WRITE NEW_TABLE,@ID)

In the mailing, the document entitled "Understanding Revelation Software's Licensing Policies and Procedures: Restrictions and Capabilities of the OpenInsight Runtime License" does cover this in Table 1 - Programs not available with the OpenInsight Runtime License:

DICT.MFS

Disables the ability to issue the following:

   CLEARFILE - Delete all the fields

   WRITE  - Create or change fields.

   DELETE - Delete a field.

I hope this answers your question.

dsig,

In all Pick-Pick-aLikes and Oracle, MsSql, Informix etc the client to a database can create new tables (depending on access rights). ONLY RTI keeps you from creating these tables easily ..

The full (development) license obviously does not have these restrictions. The restrictions are a result of the fact that you may ship an unlimited number of free single-user runtimes. None of the products you mentioned are freely redistributable.

Cameron Purdy

Revelation Software

Jennifer

re :Your emphasis of "every site" indicates that you have a large number of installed sites that require this functionality.

As yet I have *one* installed OI site *plus* with quite a number of AREV clients. My concern is toward the future and the viability of rolling these clients into a windows version of a number of applications. A single-user DRDSP on each of these users would make an upgrade economically unjustifiable.

I'll have further discussions with David and (maybe) Gene in Melbourne next week.

Re: Advisory Board. fine, thanks

Tony

Oystein

I once read an apt quotation ….

"There is no reason for it ,it just our policy"

*We* all know how unstable AREV and OI can be in certain circumstances. Sometimes removing and re-creating an index is the ONLY solution.

That aside, I just read the "Document" which out line the "easy" way in which an end-user *must* maintain a runtime application, read that as "fix the broken index" (see Jennifer's response")

Man! I've been using AREV for 10 years and I'm confused !!

God help the "novice" end user !! Isn't our job supposed to be to make it easier for the end-user ?? Isn't that why they pay us for our expertise ??

Tony

Jennifer,

I read the "document" you linked us to. I'm sorry but ..

… adding US$750 to the cost of an application *just* to have the

"ability" to fix a broken index is hardly "more economical".

And let's be realistic for a moment. In the majority on deployments that is the extent of added functionality we are taking about!

I doubt many of the *loyal* developer community are going to *jump* at the chance to take up the *special* offers.

Here's hoping "sanity" will prevail in the future.

David

How's you forehead ?

Have you made any dents in the brick wall ?

I can't agree with you more !!

How does one get through to the "powers that be" ??

So Cameron ..

Charge a *token* fee for each runtime licence say $10-$50

and add a small amount of features to the existing runtime.

Everybody will then be happy and can get on with the job!!

.. instead of us working out ways to achieve a small result with a lot of effort !! and then worrying about being sued!!!

All we seem to be doing is repeating ourselves.

Feels like a picket line, not a "community".

Jennifer,

Thanks. But I'm even more interested to see a reply to the other posting I made at the same time. I'll repeat it here for convenience:

"I think I must be dim. I can understand a runtime licence not allowing changes to be made to an application, even so small changes as adding a new index. But I can *not* understand why RTI have decided runtime users are not allowed to fix broken indexes. Indexes do break, you know."

- Oystein -

How does one get through to the "powers that be" ??

When this thread reaches 64K or something (which will be very soon at its current growth rate) it will attain a new level of importance and corpulence, sink through the bottom of the web server and the floor below, and land on the table where the aforementioned powers are gathered with their monthly policy meeting, immediately convincing them we (you, Tony, me, etc) are right.

I hope.

- Oystein -

Jennifer:

Thank you for your response. There are a couple of issues that remain unanswered:

1.  We keep a control structure in the dictionaries of three files. These are not field definitions at all, but are used as counters / flags to processes.  For example:  in DICT.WEEKLY_SCHEDULE, we keep three date fields indicating which dates are active for several processes.  We also keep two fields %S1% %S2% which contain the last-used schedule event number for two active weeks.  These are updated programatically any time a new event line is added.  To my knowledge, writes to these fields do not pass through DICT.MFS (at least in AREV they don't) since they don't contain any structures that would trigger any system activity (no data in index field positions, no F or S flags in the Field Type position, no code structures where symbolics should be, etc.).

2. You state that "New" RLIST items cannot be created. I assume that you mean as repository items and not as command strings passed to RLIST for execution (Open List / OR_VIEW, etc.). We have a table called USER_REPORTS which allows end users to define their own RLIST sentences and execute them. We use RLIST's ability to parse the sentence and return errors for correction. We publish the names of dictionary elements available for user reporting as part of our documentation. I assume that this is still "Legal".

Don Miller

C3 Inc.

Cam:

My what a wonderful can of worms has been opened here. Your statements about shipping an unlimited # of copies without license cost speaks to one issue. However, it borders on negligance for me as a developer to ship a product (even if it is "Locked Down") which lacks the facility for self-repair of data. From my experience (and I'm sure yours as well), the Rev developer community has always shipped more than averagely robust line-of-business software. One of the reasons we pick AREV / OI is that we rarely have to say "No" to our clients. That said, most of us couldn't conceive of the fact that we would lack the ability to repair a damaged table (FIXLH, etc.) or to fix a broken index (even on a single-user system) since it was inherent in all other RTI products before. In fact, Windows (all flavors) as a run-time environment is inherently less stable than tatty old MS-DOS, and therefore exposes data to far higher risks of damange. It seems to most of us that RTI ought to be able to accommodate some "mi

ddle-ground" that would satisfy its need to generate revenue from its efforts and to provide us with some needed functionality for our customers. Perhaps you can market some plug-in capabilities as an extra cost item (nominal license fee to developers would probably sit well).

Oh Well, so much for the soap-box.

Don Miller

C3 Inc.

Oystein:

I hope you're right. Mostly Jim is sympathetic to this issue (I think). Just keep piling it on. The more of us that join this, the better the chances.

Don Miller

C3 Inc.

Cameron,

I understand the need for a runtime vs developer version BUT I see no reason why table, column and index creation/modification AND FIXING should be out of a runtime system. With these under control of the developer the user would not be able to do anything willy-nilly.

[email protected] onmouseover=window.status=you have seen the rest .. now try the best!;return(true)"

David Tod Sigafoos ~ SigSolutions

voice: 503-639-8080

Hi Tony,

If I understand you correctly, you have deployed your OpenInsight application using runtime licenses and with the applicable network products (either the NLM for Netware or the NT Service for Windows NT based networks) and your sites are having problems with corrupted indexes. Could you provide more details on this problem so that we can resolve the technical issue?

Thank you,

Cameron Purdy

Revelation Software

Tony,

If you would like to discuss the license issues in further detail, I can set up a meeting between you and Jim Acquaviva when he is in Melbourne next week for the Australia conference. Alternatively I can arrange a conference call for after Jim's return the following week.

Please let me know ([email protected]) which would be more convenient for you.

Thanks,

Jennifer Scheer

Jennifer,

I think a face-to-face meeting with *all* interested parties would be best, because I *know* I'm a *very little* fish in the *very big* sea of OI/AREV users.

And I also *know* this issue goes to the very *heart* of what we do for a living and why we chose AREV/OI!

So why not post an open invitation to all attending the conference to sit down and discuss this issue so that it can be resolved by compromise ?

I also think a continued public discussion of this issue remains the most effective way to resolve it rather that by private emails.

Regards

Tony

[notag]If the discussion takes place at Melbourne can someone please tape it?

Thanks

[<A HREF="mailto:[email protected]" onMouseOver="window.status='Why not click here to send me Email?';return(true)">Andrew McAuley</A>]

[<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Why not click here to visit our web site?';return(true)">Sprezzatura Ltd</A>]

[<I>World Leaders in all things RevSoft</I>]

[<img src="http://www.sprezzatura.com/zz.gif">]

[<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0";}end hiding from non-JS browsers –></script>] [<FORM ACTION "" METHOD=GET NAME="TOCNavigator" <SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()"> <OPTION>Pull down this menu to choose whereabouts on Sprezz site to go <OPTION VALUE="http://www.sprezzatura.com">Home Page <OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New <OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL <OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST <OPTION VALUE="mailto:[email protected]">Send mail to support at Sprezzatura <OPTION VALUE="mailto:[email protected]">Send mail to sales at Sprezzatura </SELECT> </FORM>][/notag] </QUOTE> —- === At 20 FEB 1999 10:19AM [email protected] Sprezzatura Ltd wrote: === <QUOTE>[notag][<I>Fixing</I>] is a different issue and is covered by laws which supercede licensing. As Scott has been pointing out it is possible on a runtime. [<A HREF="mailto:[email protected]" onMouseOver="window.status='Why not click here to send me Email?';return(true)">Andrew McAuley</A>] [<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Why not click here to visit our web site?';return(true)">Sprezzatura Ltd</A>] [<I>World Leaders in all things RevSoft</I>] [<img src="http://www.sprezzatura.com/zz.gif">] [<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0";}end hiding from non-JS browsers –></script>]

[<FORM ACTION "" METHOD=GET NAME="TOCNavigator"

<SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()">

<OPTION>Pull down this menu to choose whereabouts on Sprezz site to go

<OPTION VALUE="http://www.sprezzatura.com">Home Page

<OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New

<OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL

<OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST

<OPTION VALUE="mailto:[email protected]">Send mail to support at Sprezzatura

<OPTION VALUE="mailto:[email protected]">Send mail to sales at Sprezzatura

</SELECT>

</FORM>][/notag]

[notag]It is our understanding that the Revelation Software stance is [<I>currently</I>] that end-users may not generate reports that alter either the fields displayed in a report OR the selection criteria used (although they can alter the parameters passed into a selection statement). This is regardless of whether you are using OpenList, R/List or a third party utility. To do so you must purchase developer ready licenses or copies of Report Designer. It is assumed that once you have bought report designer you have bought a reporting licence and may then use R/List again.

This stance is primarily what is delaying the next SENL as we try to document this. (It obviously has implications on people's usage of S/List).

[<A HREF="mailto:[email protected]" onMouseOver="window.status='Why not click here to send me Email?';return(true)">Andrew McAuley</A>]

[<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Why not click here to visit our web site?';return(true)">Sprezzatura Ltd</A>]

[<I>World Leaders in all things RevSoft</I>]

[<img src="http://www.sprezzatura.com/zz.gif">]

[<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0";}end hiding from non-JS browsers –></script>] [<FORM ACTION "" METHOD=GET NAME="TOCNavigator" <SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()"> <OPTION>Pull down this menu to choose whereabouts on Sprezz site to go <OPTION VALUE="http://www.sprezzatura.com">Home Page <OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New <OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL <OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST <OPTION VALUE="mailto:[email protected]">Send mail to support at Sprezzatura <OPTION VALUE="mailto:[email protected]">Send mail to sales at Sprezzatura </SELECT> </FORM>][/notag] </QUOTE> —- === At 20 FEB 1999 03:34PM Jennifer Scheer wrote: === <QUOTE>Tony, My intent is not to halt discussion on the topic but to find an appropriate forum to determine whether or not any actions need to be taken. My point is only that this forum is a forum for discussion and clarification, not for policy change. All I can do here is to reiterate our licensing policies and practices. No changes will be made to our policies and practices on this forum (I am not saying that opinions posted here are not taken into consideration). I encourage you to take the opportunity at the Australia Developers Conference to discuss this issue with Jim Acquaviva. </QUOTE> —- === At 21 FEB 1999 07:17AM Tony Lillyman wrote: === <QUOTE>Andrew, With the consent of all parties - by all means!! I understand you guys have a big issue with this as well so maybe we'll make some progress. Here's hoping! Tony </QUOTE> —- === At 22 FEB 1999 01:26AM John Curby wrote: === <QUOTE>Tony, Here, here. I'd be happy / interested to sit in on a roundtable at the conference (or after). I believe there is scope for limited relaxation of the existing arrangements, not neccessarily limited to only indexes. For eg, the RDK update process should allow addition of tables (ie CREATE_TABLE) to allow for additional functionality to be added to an existing runtime system, and therefore addition of indexes, etc. In the days of AREV, although a runtime licence fee applied, the developers' lot was in some ways a lot easier, as systems could be truelly prototyped (rather than locked and restricted). Well that's my 2 cents after 10 years developing with Rev Tech (hands up those who remember COSMOS :). John </QUOTE> —- === At 22 FEB 1999 04:18AM [email protected] Sprezzatura Ltd wrote: === <QUOTE>[notag]Just started my 16th year with Rev products! <g> [<A HREF="mailto:[email protected]" onMouseOver="window.status='Why not click here to send me Email?';return(true)">Andrew McAuley</A>] [<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Why not click here to visit our web site?';return(true)">Sprezzatura Ltd</A>] [<I>World Leaders in all things RevSoft</I>] [<img src="http://www.sprezzatura.com/zz.gif">] [<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0";}end hiding from non-JS browsers –></script>]

[<FORM ACTION "" METHOD=GET NAME="TOCNavigator"

<SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()">

<OPTION>Pull down this menu to choose whereabouts on Sprezz site to go

<OPTION VALUE="http://www.sprezzatura.com">Home Page

<OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New

<OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL

<OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST

<OPTION VALUE="mailto:[email protected]">Send mail to support at Sprezzatura

<OPTION VALUE="mailto:[email protected]">Send mail to sales at Sprezzatura

</SELECT>

</FORM>][/notag]

Hi John,

I believe there is scope for limited relaxation of the existing arrangements, not neccessarily limited to only indexes. For eg, the RDK update process should allow addition of tables (ie CREATE_TABLE) to allow for additional functionality to be added to an existing runtime system, and therefore addition of indexes, etc.

Application of an RDK upgrade can add/create/remove/modify dictionary items, indexes, tables, etc. In other words, you (the developer) can send your customers updates to your application which may modify the application components including the database. The runtime license prohibits the use of the development tools and it disallows the application from making these types of changes itself.

Cameron Purdy

Revelation Software

Hi John:

My experience with RTI goes back to working with Roger Harpel and Mike Nourse in writing the original release of Revelation. Things were much simpler then..remember when it would run on an XT with a 10MB hard disk? I think the OI restrictions on RDK activities are almost negligent in their impact. The inability to repair GFE's or Damaged Btrees via modem or to allow for ad-hoc use of R/LIST in a template (like the old Queries table in AREV) pretty much negates the notion of using a robust database tool for anything but expensive or custom-written apps. A generalized package deployed across a large, geographically dispersed universe will become expensive for users and for us (the support implications are truly horrendous).

Don Miller

Don,

I saw your questions, let me attempt to give them a shot…

]

I checked the source code in OpenInsight and as I expected you cannot update the dictionary with %% fields in a Runtime. This reflects our runtime licensing since you cant create/modify dictionary fields in a runtime. Therefore , if I were in your shoes, I would place this information in either a configuration file (you could automate this with an easily identified key such as TABLENAME*%S1%) or you could be a brave and put the %S1% field in your data table (like we do with quickdex/rightdex of your data table)

]

From your description, I doubt this is allowed in a runtime, but to make sure -I have some questions for you - Please give me a call so I can see what you are doing - or if you would like to send me some sample code that illustrates your question - I would be happy to take a look at it (you can email me at [email protected], my phone is 978 946-7165)

Best Regards,

Kurt

Don,

I might have sold you down the river on the %S1% fields - I'm going to recheck the source code - I'll let you know. Regardless, I still recommend my earlier suggestions and not store the info in the dictionary.

I'll let you know what I find out (It looks like I'm going to have to go back to school and relearn how to read source )

Kurt

Cameron,

We have a number of small sites using Windows 95 networks and the NPP. These get corrupted indexes and they get GFE's in the index files. We had one NLM site that had numerous problems with GFE's in the index files. It turned out to be a problem with the driver for the disk controller card in the server, but we still had to fix the corrupted indexes. Most sites with the NLM or NT service do not seem to get GFE's, but still have indexing problems. The problems may have nothing to do with the LH engine. It could, for example, be the result of a hardware problem, configuration issue, etc. For example, we see Link List errors in the indexing, or we run across index updates that do not seem to occur. For example, a record is deleted but the related key is not removed from the destination record. We may not always know why. These problems occur at sites with dedicated index machines, with a UPS on everything. The point is, in the real world, indexes get corrupted, even if you use the NLM or NT Service.

View this thread on the Works forum...