Hi.

I have been testing Universe and Unidata from OI, and I see some really interesting benefits in working with U2 databases, starting with the fact of turning a OI application into a real client-server solution.

On the other hand, I think that all this would work only if you can really trust the bond 100%.

I found the following problems through the testing and I would like to know if they are going to be fixed and when:

1. An RList SELECT WITH A_DATE GE "X" AND A_DATE LE "Y" doesn't work against Universe or Unidata.

2. An RList SELECT WITH A_DATE GT "X" AND A_DATE LT "Y" does work with Universe.

3. An RLIST SELECT against Unidata works OK if the SELECT returns a relatively small number of keys (less than 1000). A SELECT that returns more keys (2000 or more) fails with "Invalid Target Type 7".

4. OI doesn't build the shadow DICT of a Universe table with a name longer than 11 characters. This seems to be because Universe is using 8.3 format for the folders of these tables, but I don't have much more experience with Universe.

Finally, I still have not clear what are the main differences between Universe and Unidata. Both of them seem to work fine and to be faster than OI native tables. As a begginer, I would like to hear the opinion of someone who has worked with both of them to orient me about which one to choose. I have the feeling that Unidata is a little faster than Universe, but may be I'm wrong.

Thanks,

Enrique

Enrique - have you tested selects with the 8.0 beta?

I believe that the large select issue is resolved.

I will look at the LT vs LE and long file name issues. I was not aware of either.

The newsgroup comp.databases.pick might be a good place to ask your Universe versus Unidata question. OI is more directly related to Universe, so Universe may feel more familiar

- Bob

Unfortunately, I don't have a OI 8.0 beta. Is it already available?. I would like to have it. Who do I have to contact with?

I will take a look at the newsgroup. By the moment, I alternate tests over one database and the other. I have to say that Unidata looks more like ARev than Universe.

BTW, are you using NLSMODE in Universe?. As I have my OI application in UTF-8 mode, I guessed this would be the right thing to do, but then I didn't see any UTF8 character set in Universe and I had problems when moving tables from one Universe system to another in a different machine because of the NLSMODE. Should OI in UTF-8 mode work fine without NLSMODE on?

Thanks.

Enrique

I'll get you a link for the beta.

I have not worked with the NLS mode, will need to look into it.

Bob

Unidata is more like Arev (pick O/S character screen interface) and UniVerse is more like OI.

For what its worth, I prefer uniVerse over Unidata (U2).

Am I confused? UniVerse is accessed by a telnet session. Right?

U2 is traditionally accessed by telnet, or by a third party application which treats the U2 database as the server in a client-server relationship.

Recent versions of OpenInsight include the U2_BFS which lets one attach Universe or Unidata tables and work with them as if they are OpenInsight tables. This means you can put an OpenInsight front on on an existing U2 application, or host the data from your existing OpenInsight application on a Universe or Unidata server, or build a pure multivalue client-server solution. Revelation and IBM are working together to make this a successful environment.

Bob:

I downloaded OI 8.0 and I am testing the U2 stuff. Here are my first results:

Database Manager:

I see great enhancements in the U2 connection window and in the Database Manager. I haven't still tried to create tables in U2 from the Table Builder, or modify DICTS, I will test that tomorrow. I will also try to attach a table with a name longer than 11 characters to see if the dict builds OK in OI.

The only problem I found with Database Manager is the following: I defined the U2 volume in the server, attached tables and refreshed shadow dicts. When I open OI from other workstation, I don't see the U2 tables.

RLIST:

I did test again RList SELECTs over date fields and it is still not working right:

1. Selections using GE and LE return the entire table.

1. Selections using GT and LT work OK.

NLS:

About NLS, as far as I can see, installing and enabling NLSMODE in Universe makes Universe use Unicode, and seems to work OK. I am not using any NLS map, I left the NLS map for new tables set to NONE.

Thanks,

Enrique

Bob:

More positive results with OI 8.0:

1. Creating a Universe table from OI works OK!

1. Creating a Universe table from OI with its name longer than 11 characters and it worked OK!

1. I could see and work with U2 tables from another workstation different than the server. I think the problem was that I didn't close OI on the server after attaching the U2 tables, so maybe the .DBT did not refresh properly.

Now things are going forward. Just two things are still floating around:

1. One is the selection problem with LE and GE.

1. The other one is the %SK% field of the DICTs. With OI 7.3, I was able to open the "D_TABLE" (the Universe DICT of a table) from OI, and modify an "X" field named "%SK%" in that table. Now in OI 8.0, I can't open the Universe DICT from OI, so the only way I see to store SKs is in the OI shadow dicts. From my point of view, the next sequential key should be stored at the server side. This is because you may rebuild the shadow dicts, or you may have two or more independent OI "clients" accesing the same U2 server. Where were you expecting the SKs to be stored?. At the server side, or at the OI side?.

Enrique

Enrique:

I have reproduced the problem with the GE and LE selects.

I also found that the U2_Bond returns a blank id at the end of each select. This makes @reccount one too high, for example 101 instead of 100, and a loop readnext id returns a blank id. I expect to have these fixed for the next release of the beta.

Bob

Enrique,

While it is not helpful for existing U2 applications, If you are creating a new application with a U2 backend then why store the %SK% seed records in the dictionaries at all? For years, I have used replacement seed routines which store SK*tablename seed records in my controls table. Some advancements with this approach are: (1) assigning the key at LOSTFOCUS time; (2) tracking abandoned keys to eliminate holes; (3) including literal prefixes or additional key parts in the sequential keys.

Gerald

Gerald: I agree with you. I am only using the %SK% only in small tables who have a window associated to the database. Most of the windows of the application except those mentioned before are not database-associated, and I use a subroutine when the "Save" button is pressed to look for the next available key. Actually, the subroutine that looks for the key looks for it in the DICT of the corresponding table, but it may be easily changed to look for the SK in a "Table of SK". That's a good idea. Maybe I was too used to the ARev/OI style to see it.

Thanks

In principle, I'm OK with %SK% in the dict of the table, as I think of the counter as a property of the table. In practice it's easier to control and deploy the counters if they are in one place.

Either way, I agree that the counters belong on the server. I was thinking of %FIELDS% and %PROTECT.SPEC% when I set the bond to not pass through "%" Fields. I'll refine the filter in the BFS.

Bob

View this thread on the Works forum...