Hi All

This problem is one of those weird ones, ie it shouldn't be happening. Well aren't they all.

We have an OI application which "attaches" Arev tables from another applicaiton.

The problem is that the OI application is not doing a very good job of attaching the arev tables. Records that you can see in Arev do not show up when you report on the table using OI. If you copy or create a record in AREV the new record does not show up in OI. The index tables are not attached in OI - I don't know why, or if this matters.

If I use system editor to copy records, the new ones show up fine.

Related? is a volume attachment problem where the OI app says the whole volume is not attached but when you listvolumes from system editor, it shows that the volume (directory) is attached but you get a "not attached" error if you try to detach it, and if you try to attach it you get an already attached error - we cant win.

Systems are

OI V3.3, Arev V3.12, Novell Lan, and Win 98 workstation.

How do I find out what version the NLM is and could this be causing some of the problems?

Has anyone else had similar problems, and how do you fix it.

How do I find out what NLM the AREV is using? Does it matter?

I think the OI app is set up as "standalone" or single user but the Arev app is networked and the arev tables do not reside on the same PC as the OI app, ie the OI app is attaching the arev tables across the network. Could this be causing a problem?

Does the revparam file with serveronly=1 in the arev table directories make a difference? If I put this in the arev table directories will this stop OI from working if the OI is single user/standalone? Does the revparam file affect the way Arev works (actually I know the answer to this one=YES, having the revparam file breaks the arev system on an NT Cluster arrangement). I will try to find out if there are revparam files and what network driver setting the OI system is using.

I found a related problem posted by Mark Glickman in May 1999 but it doesn't have enough info to help me. His solution was the last post in the series.

attempting hyperlink to Mark's related problem:

AREV 3.12 and OI 3.5 Problem

Scott, LMS

Scott,

I have never heard or seen a problem where records visible in AREV are not visible in OI. I don't believe this is a result from not having the indexes attached, but I am surprised that you don't have other problems because of this. I suppose you could attach the indexes and prove whether this is the problem or not.

I am assuming that these AREV tables are all correctly named (i.e. not dots) and the columns are all properly named and typed (i.e. no dots and no missing data types.) Also, you will have trouble attaching tables in a volume if they are not compliant with OI's requirements.

If I use system editor to copy records, the new ones show up fine.

I'm not sure what you are implying here. What are you copying the records from and to what table?

The version of the NLM would be the same for OI and AREV, since they are presumably running on the same server. However, the client driver may be a different version which will definitely cause problems. Here's what you want to know:

1. Get the version of the NLM by typing "MODULES" from the command prompt of your Novell server. This will list all your NLM's one page at a time. The two you want to look for are LH.NLM and LHIPXSER.NLM. Alternatively I think you can also type LHSTART from the command prompt. This attempts to load these NLM's. Since they are already loaded it should tell you the versions of these files. (BTW, you never mentioned what version of Novell you are running.)

2. Get the version of the TSR that AREV is running by typing LHIPXTSR at the command prompt where AREV exists.

3. Get the client driver that AREV is running by typing WHO from TCL.

4. Get the client driver that OI is running by running the NETDRV.EXE utility that should be in the same directory where OI exists.

The version numbers for all of these should be the same. If you are not running Novell 5.x then this version should be 1.5 or 1.5a (some of the above won't show the "a" at the end.)

The "ServerOnly=1" setting will prevent OI from attaching the folders if OI is not successfully working with the NLM. This is a safeguard against improper configurations from accessing tables and possibly corrupting them. If you are not already doing this, you should.

Let us know if you discover anything else that might be useful.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Hi Don

] I suppose you could attach the indexes and prove whether this is the problem or not.

I thought the indexes would be in the same volume/directory as the main tables but maybe not. Ie if they are in the same volume why aren?t they attached? I will check.

] I am assuming that these AREV tables are all correctly named (i.e. not dots) and the columns are all properly named and typed (i.e. no dots and no missing data types.) Also, you will have trouble attaching tables in a volume if they are not compliant with OI's requirements.

I will find out, I suspect they are ok but not sure. Give me an example of how a table/volume might be ?not compliant? or do you mean the suggestions you made about the dots etc?

]]If I use system editor to copy records, the new ones show up fine.

]I'm not sure what you are implying here. What are you copying the records from and to what table?

Ok, I admit we have two related problems, one where we can see some of the records in a ?successfully? attached table and another where we cannot see any tables in a ?successfully? attached volume. So I can copy records within an attached table (ie recname1 to recname2 in tablename1) using OI or AREV. If I use AREV, OI cannot see recname2.

I will try all the stuff about NLMs you said. Typing commands on the Novell server could be interesting because I don?t have access to it. You know how management outsources the LAN management to some big international conglomerate (IC), which means the people providing application support can?t get at the LAN. My favourite is when the IC upgrades the server software and then OI is no longer compatible.

]The "ServerOnly=1" setting will prevent OI from attaching the folders if OI is not successfully working with the NLM.

I suspect this may be closer to the problem because the OI is installed on the workstation hard drive ie not networked and the AREV is installed on the LAN. I suspect this combination is not compatible but I suggested changing the netdrv.exe thing for OI to allnetworks instead of the novell IPX or single user.

I will endeavour to find out more about what is going on, this is beginning to get like chinese whispers.

Scott, LMS

Janet,

…this is beginning to get like chinese whispers.

I'm not familar with the term chinese whispers. Could you please clarify?

Thanks,

Ray Chan

Scott ..

If the data tables are on a Novell server with the NLM controlling them, then the OI app should use the IPX driver that ships with the NLM instead of All Networks or Byte Range. Make sure that the access rights to the server tables are correct for the user workstation running OI. The fact that you can write a row to a table in AREV but can't read it in OI seems to indicate that the table was extended by the write in AREV on the server and that the workstation was not able to detect this fact. Frankly, I've never mixed stand-alone and networked access across apps. Maybe that's like playing russian roulette with a machine gun.

Don Miller

C3 Inc.

My first question is: Is your name Janet or Scott? I'm starting to get confused

I thought the indexes would be in the same volume/directory as the main tables but maybe not. Ie if they are in the same volume why aren?t they attached? I will check.

OI typically works off of an attach image which is stored in the appname.dbt file in your OI application directory. If the data/dictionary tables are in there but the index tables are not, then it won't matter if your index tables are in the same volume. Now having said that, it would be unusual for the indexes not to be defined in the .dbt file since OI's Database Manager will attach all corresponding tables when the pointers are being defined. The most likely cause (if this is indeed what has happened) is that the indexes were created by AREV after the OI app defined the tables in its .dbt file. Alternatively, like you suggested, the index tables could exist in another volume and they should be added to the attach image using the Database Manager.

I will find out, I suspect they are ok but not sure. Give me an example of how a table/volume might be ?not compliant? or do you mean the suggestions you made about the dots etc?

I meant the dots. I'm not aware of a volume naming problems, just table and columns.

So I can copy records within an attached table (ie recname1 to recname2 in tablename1) using OI or AREV. If I use AREV, OI cannot see recname2.

This is very strange. Are you trying to view the records from a data window or from OI's System Editor after an AREV copy? Are there any custom MFS's on this table. Any relational indexes?

I suggested changing the netdrv.exe thing for OI to allnetworks instead of the novell IPX or single user.

Like the other "Don" said, this will be a problem if the OI driver does not use the IPX driver.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Ray:

Try Here

Mike Ruane

Not at all- I was unfamiliar with the term myself and did a search on it.

If I caused any offense I humbly and profusely apologize.

Mike Ruane

Mike,

Sprezz as an organisation is one of the least PC places you could find. So there is virtually nothing you could say to offend us. I suspect that the same robust view of the world pervades most forum members. I am sure you have nothing to apologise for. We merely postulated the possibility of a tongue in cheek "heads up". We'll probably now be embarrassed when Ray thanks you profusely for enlightening him.

It is however interesting to reconsider our everyday language from time to time in the context of the community we find ourselves in.

and off the soap box…

Scott/Janet,

Are you doing a "Set-Alias" on any of these volumes that don't appear to be attaching correctly. If you do a set-alias, the volume will show as attached by "Listvolumes" but all the files in that volume won't actually be attached.

Scott / Janet,

It would appear that there are a number of possible problems here.

If the indexes on the tables were created in Arev, and the tables were attached to OI later, then do the data tables have SI.MFS applied within Systables (DBT)?? If not, then you will need to delete the indexes from Arev and re-create them via OI. This will apply the necessary to both OI and Arev.

Alternatively, I have come across situations where indexes created in Arev and seemingly OK in OI still do not update correctly unless created in OI.

Also, if the index files are not attached, and a selection is using an indexed column, then no hits will be returned from the selection.

As an overview, I am recommending that all indexing is removed via Arev, re-created via OI and the database saved.

Simon

Rebus Software (UK) Ltd

Scott (or is it Janet?),

Do you do a set-alias, alias_table to any of these volumes? If you do a set-alias then listvolumes will show the volume as attached but the other files in the volume won't be available.

Scott / Janet,

It would appear that there are a number of possible problems here.

If the indexes on the tables were created in Arev, and the tables were attached to OI later, then do the data tables have SI.MFS applied within Systables (DBT)?? If not, then you will need to delete the indexes from Arev and re-create them via OI. This will apply the necessary to both OI and Arev.

Alternatively, I have come across situations where indexes created in Arev and seemingly OK in OI still do not update correctly unless created in OI.

Also, if the index files are not attached, and a selection is using an indexed column, then no hits will be returned from the selection.

As an overview, I am recommending that all indexing is removed via Arev, re-created via OI and the database saved.

Simon

Rebus Software (UK) Ltd

Hi All

I am Janet Scott, ie both are my name and that pesky password thing meant that when I posted in too much of a hurry I forgot to edit the author field (which you can still do but not after you press the submit button). I work for LMS, well it isn't LMS any more because they changed their name but that's a silly story in itself, LMS has more history and it''s shorter so I still use that. So consider this all you not so PC. I never said that Scott was my first name. You made assumptions all on your own. I've had this experience before. I prefer the assumptions that you make about my technical ability when you assume I'm a bloke.

So I concede - sprung.

About the chinese whispers, if it is any comfort, it doesn't matter what nationality plays it, the results are funny. In fact if you mix players of different nationalities it becomes funny faster.

So about the technical stuff.

I don't think it would be good idea to remove the indexes from the AREV application because that is the main application, the OI app is just an optional extra.

I agree mixing apps installed on PC hard drives with apps on the network is messy. I haven't had any success with it before so why should now be any different.

The apps in question don't seem to be controlled by the server NLM because there are no revparam files. All versions of things seem a bit old. The OI app (on the hard drive) was running all networks v1.4 or similar. Our other OI apps are up to at least 1.5. The guy who is working on this system (hence the translation problems/chinese whispers) is going to try changing the OI netdrv to an IPX driver. I have no idea if this would be the same type of NLM as the Arev app is running.

I don't know if the volumes are aliased or not. How do I check that? As far as I know some of the arev tables are indexed and we have attached the entire volume but no !files show up in the systables for OI to match the arev tables. Do Arev indexes look different? What if we created Index tables for the AREV tables in OI? Would that break the Arev app? I doubt the arev app indexes were created after the OI app. The arev system is much much older. The aliasing could be a problem for at least one of the volumes, apparently some of the volumes are aliased. This might explain why the tables in one volume don't show up at all. Why does aliasing affect this and how do you get the tables to show up in an Alias'ed volume?

Changing the Netdrv to ipx for the OI app does seem to have fixed some problems (maybe the ones about records not appearing).

hope you are all still checking this thread.

Scott, LMS

PS any chance of persuading RevTech to change the way the threads put together with the main thread (the Open Insight page) listing most recent first but the sub threads like this one listing with newest added to the bottom?

Hi all

Scott and Janet are both names of mine. It isn?t my fault you made certain assumptions based on the name Scott. I prefer the assumptions you make about my technical ability when you assume I?m a bloke so I never corrected any assumptions either. You can edit the author field before you submit but not after and I posted in a hurry and forgot.

About our game of chinese whispers. I wrote a whole post and the system ate it so I am writing it again. Apologies if you get the first version.

We have changed the OI (hard drive) app netdrv from all networks to the IPX driver and that seems to have solved some problems with the no show records. Yes I was trying to look at them with system editor. They didn?t show up in the app forms either when they were supposed to.

There may be some additional problems associated with aliasing. How do I find out if a volume is aliased? If it is aliased how do you get to see the tables in it? Why don?t they show up normally.

Indexing. I think the arev tables ? some of them anyway, have indexes. These indexes would have been built way before the OI app. No tables with ! show up in systables in OI even though the volumes are attached and you can see some of the arev tables. Why?

The server NLM doesn?t seem to be controlling anything, there are no revparam files in the arev directories.

I don?t think there are any dots in the column names or table names.

Well stuff knows where the first attempt at this post went.

Scott, LMS

keyword Wally

Janet Scott,

…sprung

I'll come clear too. Oystein's really my husband's name.

He did write some of the postings signed with his name, though. Just look for the ones with the really silly questions.

You didn't believe that, did you?

I don't know if the volumes are aliased or not. How do I check that?

(I didn't know a volume itself could be aliased. Can it???)

Try a

run rlist "LIST SYSTABLES F2 BY @ID", 1

in the System Editor Exec Line. I think for the aliased tables the first column will contain the alias, and the second column the real name.

run rlist "LIST SYSTABLES F2 BY @ID WITH @ID F2", 1

should list just the aliased ones.

But I'm not an expert on this stuff. I think I have unresolved issues with aliasing in my own app. Fortunately it's not often my clients need the feature affected by the problems.

PS any chance of persuading RevTech to change the way the threads put together with the main thread (the Open Insight page) listing most recent first but the sub threads like this one listing with newest added to the bottom?

I don't mean to be rude, but my guess is they don't have a clue how to do it. They haven't even managed to fix the links so you can see which postings you've already read. Just look at the links in the Flat by Date page versus the links in the thread at the bottom of the Document page (or whatever it's called, the page you read my posting in now). If you click a link in one of those pages, it doesn't show as read in the other page.

But talking of threads - your latest postings seem to have become disconnected from their thread. I think that can happen if the postings you respond to have been edited after you responded. Which is not a standard feature of the discussion site. But some of the guys (oops!) out there know how to do it.

- Oystein -

PS. I fear my response isn't much help. But at least somebody is still checking this thread.

Janet,

Regarding seeing the indexed tables (non-aliased, attached)

You will probably need to do a Set_MFS on the affected tables for SI.MFS within OI. You will need to take it off first because it is aleady on in Revmedia and then re-apply it. I would then do an attach table for each index table and finally do a Define_Database.

As for aliased tables, I am not sure. You could try doing the same (or smiilar) but I don't know what the results will be.

Best of luck

Simon

Rebus Software (UK) Ltd

View this thread on the forum...