I've posted this on the regular OI discussion - but I haven't heard anything yet, and we're basically stuck with this until we can resolve it:

When I do a full deployment of our application (runtime):

- none of the indexes are showing up in the runtime environment

- none of the users we had set up are showing up in the runtime

The users I can handle by running the database manager against the runtime and setting them up - I 'thought' they would of come over during deployment if they existed in the original application.

The indexes are a little more confusing - they are not appearing in the runtime, and according to the database manager there are no indexes on any files - and of course, in the runtime environment you can't add any new indexes. Am I missing something in the deployment? The !filename shows up as publishable, but does not actually appear on the list of tables to deploy (it also seems odd that the !filename files don't show up in the repository either).

Another related question - if you want to add an index to a file after deployment, how do you do it?

Thanks for the help,

Jeff

Jeff,

none of the indexes are showing up in the runtime environment

They should … is there anything special about your setup? For example, are your dictionary and data files in different directories? Are the indexes from an older version of Arev? etc…

none of the users we had set up are showing up in the runtime

That is expected. Use the database manager to create them or see Create_User in the help file.

Cameron Purdy

[email protected]

]] none of the indexes are showing up in the runtime environment

]] They should … is there anything special about your setup? For ]] example, are your dictionary and data files in different ]] directories? Are the indexes from an older version of Arev? etc…

Cam - I don't think that there's anything 'special' about this file. The files were originally created in OI, the data/dictionary/!file are all located in the same directory under the development copy. All three files actually show up in the runtime - but the indexes are not recognized. The only thing I can see that raises a question in my mind, is that the directory under the development copy is named differently than the runtime directory, and I don't see anyway to control this. We have the files seperated logically under the development copy, and when we deploy, the files go into the default 'data' directory. Could this have anything to do with the problem? Do we need to use the NAME_VOLUME command at some point? BTW . . . where might I find the syntax of that command?

Thanks,

Jeff

Jeff,

I don't think that there's anything 'special' about this file. The files were originally created in OI, the data/dictionary/!file are all located in the same directory under the development copy. All three files actually show up in the runtime - but the indexes are not recognized.

So it deploys the tables successfully, but the indexes are missing? I want you to try one more thing:

1. Drop all indexes off that table

2. Verify that the ! file is gone

3. Put the indexes back on

4. Try to deploy

If it doesn't work, you ship me that file, and I will try to resolve it by 3.6.

Cameron Purdy

[email protected]

Cam,

I tried:

- removing all indexes/rebuilding/deploying - no change

- removing all indexes/name_volume to match runtime volume/rebuild indexes/deploy - no change

- removing all indexes - moved file (copy_table) to 'DATA' directory/rebuilt indexes/deploy - no change

- I created a new file (in datavol), added a couple records, created an index, deployed - no indexes show up in the runtime version.

If you'de like me to send one of these files I can - let me know. Are you saying that you can do this and it works? I'm using OI 3.5, NLM, Novell 3.1x server, etc.

As I mentioned already - the !filename is showing up in the runtime version - but if I try to list indexes from the Database Manager under the runtime version - it says there are no indexes. Also, routines we had written to do index lookups don't work.

Thanks,

Jeff

[email protected]

Jeff,

Are you saying that you can do this and it works?

I asked Q/A to test this feature yesterday and it worked fine. It sounds like there is something that is causing the table deployment to fail … perhaps a problem in your database definition. I'd like to see it so we can provide a fix to the problem (if it is an OI bug) or a utility to search for and fix the problem or at least a knowledge base article on what could cause this. Is there any way I could get a complete copy of your dev environment (including your database)? Could you send a ZIP disk, a JAZ disk, or a CDR overnight? I want to make sure we get this resolved for 3.6 and we're running out of schedule.

If you can send it, the mailing address is:

Revelation Software

Attn: Cameron Purdy

201 Broadway

Cambridge MA 02139

If you can zip it up small enough, you can email it to [email protected].

I appreciate your persistence in helping us to get this problem resolved.

Cameron Purdy

[email protected]

Jeff,

Thanks for sending your system.

I wrote a quick program to thoroughly scan your system for indexes:

<code>
function Find_Indexes(void)

$insert Logical
$insert Dict_Equates

* make a list of tables with dictionaries
List="
Tables=@tables
cTables=count(Tables, @fm) + (Tables # "")
for i=1 to cTables
  if Tables[i]1,5=DICT." then
    List=Tables[i]
  end
next i
transfer List to Tables
cTables=count(Tables, @fm) + (Tables # "")

* check each dict field
List="
for i=1 to cTables
  Table=Tables[i]
  open Table to f then
    select f
    eof=FALSE$
    fAny=FALSE$
    loop
      readnext Key else eof=TRUE$
    until eof
      if Key1,1 # "%" then
        read Rec from f, Key then
          if Rec then
            List=BTree on ": quote(Key): " in ": quote(Table6,99999)
            fAny=TRUE$
          end
          if len(Rec) then
            List=XRef on ": quote(Key): " in ": quote(Table6,99999): " using ": quote(Rec)
            fAny=TRUE$
          end
          if len(Rec) then
            List=Relational on ": quote(Key): " in ": quote(Table6,99999)
            fAny=TRUE$
          end else
            if len(Rec) then
              List=Related info for ": quote(Key): " in ": quote(Table6,99999): " without a relational index"
            end
          end
        end else
          List=Unable to read ": quote(Key): " from ": quote(Table)
        end
      end
    repeat
    if (fAny) then
      locate "!": Table6,99999 in @tables using @fm setting Pos else
        List=Missing index table ": quote("!": Table6,99999)
      end
    end
  end else
    List=Unable to open ": quote(Table)
  end
next i

swap @fm with \0D0A\ in List
return List

</code>

It reported the following:

<code>
run find_indexes

BTree on "APPUSERSTATUS" in "SYSREPOSLOCKS"
BTree on "CITY" in "TEMPB52AE8C00000S"
Missing index table "!TEMPB52AE8C00000S"
BTree on "CITY" in "CONTACTS"
BTree on "NAME" in "JEFFTEST2"
Request successfully executed.  1 row(s) processed.

</code>

That TEMP problem is probably from a test run of the contacts window or from Table Builder when you blew up or something (suggestion, always use the real data file), so I did the following:

<code>
run delete_table 'DICT.TEMPB52AE8C00000S'

</code>

That was a big mistake! Somehow, the DICT.TEMPB52AE8C00000S table was pointed at DICT.CONTACTS … I deleted your dictionary. So I reinstalled from the ZIP and checked REVMEDIA:

<code>
DICT.CONTACTS*GLENN  REV21295  
!CONTACTS*GLENN      REV21296  
CONTACTS*GLENN       REV21297
...

</code>

Notice that the temp file isn't listed! I opened 'DICT.TEMPB52AE8C00000S' and sure enough it was pointed at REV21295 … so this time I detached it:

<code>
RUN DETACH_TABLE 'DICT.TEMPB52AE8C00000S'

</code>

Now my test reported correctly:

<code>
run find_indexes

BTree on "APPUSERSTATUS" in "SYSREPOSLOCKS"
BTree on "CITY" in "CONTACTS"
BTree on "NAME" in "JEFFTEST2"
Request successfully executed.  1 row(s) processed.

</code>

… as did the list indexes function in DB manager … so I saved the database and deployed. It did not, however, deploy the indexes.

What I found was that:

1) If you deployed your data tables empty, the index files (!) were not created in the deployed copy.

2) If you deployed your data tables with data, the index files were there but not in the database definition, so you had attach the DATA directory.

<code>
run list_index
Request successfully executed.

run attach_table 'DATA'
Request successfully executed.

run list_index
CONTACTS	CITY	1	0	0
JEFFTEST2	NAME	1	0	0
Request successfully executed.  2 row(s) processed.

</code>

So there is a bug in there somewhere with ! file deployment … maybe this can give you enough info to work around it until 3.6. Let me know ….

Cameron Purdy

Revelation Software

Cam,

Thanks for verifying the problem, I'm glad we're not just going crazy. So I understand what you found - just by 'attaching' the data volume in the runtime version, the indexes show up? (I'm not at work right now or I would try it). Does that need to be done everytime the runtime is started, or by attaching once it cures the problem?

The 'temp' dictionary file you found wasn't always there (I forgot about it actually). It appeared yesterday as an 'alias' in the deployment definition. I didn't know where it came from, I tried to get rid of it but I couldn't find where to delete an 'alias'. Where do you? I couldn't find it in any of the 'sys' files.

Keep me posted on what you find out - I'm curious about it myself at this point . . .

Thanks again for the help,

Jeff

Jeff,

just by 'attaching' the data volume in the runtime version, the indexes show up?

If you deploy the data tables with data, the ! files are there but not attached. If you deploy the data tables empty, the ! files are not there (apparently a bug).

I know this works under some circumstances (i.e. in our RDK testing on in-house systems) which makes me wonder if it is a config issue.

Does that need to be done everytime the runtime is started, or by attaching once it cures the problem?

It has to be attached and then the database needs to be saved. To do this, rename the deployed OENGINE.EXE to OENGINE.BAK, copy in your dev OENGINE.EXE, log in, attach the tables, and then save the database from db manager, then delete the OENGINE.EXE and rename OENGINE.BAK to OENGINE.EXE.

The 'temp' dictionary file you found wasn't always there (I forgot about it actually). It appeared yesterday as an 'alias' in the deployment definition. I didn't know where it came from, I tried to get rid of it but I couldn't find where to delete an 'alias'. Where do you? I couldn't find it in any of the 'sys' files.

It was in SYSTABLES (which is just a view of the @tables array). SYSTABLES is all attached tables. Just detach the TEMP table and save the database definition (as per my other message).

Cameron Purdy

Revelation Software

]] It has to be attached and then the database needs to be saved. To do this, rename the deployed OENGINE.EXE to OENGINE.BAK, copy in your dev OENGINE.EXE, log in, attach the tables, and then save the database from db manager, then delete the OENGINE.EXE and rename OENGINE.BAK to OENGINE.EXE.«

One more thing . . . this works fine up until the point of 'saving' the database. When I run database manager from the runtime version (with oengine.exe renamed, etc.) - I can't 'save' the database definition, and it doesn't ask me to when I exit. I can attach the location, see the indexes (finally) - but I can't save it. If I then quit and reenter the application, I'm back where I started from.

Jeff

Cameron, I have experienced the problem as reported in this thread. We went to great lenghts to get things working in the depoyed runtime applications - and only just! I would be delighted if the issue can be nailed down for v3.6

Richard Bright

BrightIdeas New Zealand

Couldn't you place in something during the install process to attach the data tables? You should be able to attach them while the RDKMODULE install process is running.

[email protected]

Sprezzatura, Inc.

View this thread on the Works forum...