Re: Upgrade questions

>Date: Fri, 15 Apr 1994 12:04:34 -0500 >From: Troy Burns <troyb@genesis.admin.bethel.edu> >Subject: Upgrade questions >X-Informix-List-Id: <list.3819> > >The client I'm working for has the current info: > > online 5.00.UC2 > isql 4.10.UC2 > i4gl 4.10.UC2 > hardware: Sequent symmetry 2000/250 running dynix 1.3 > >They are thinking of upgrading to 7.0 when it becomes generally available >(they already realize that the OS has to upgraded). > >The question is, do they have to upgrade the isql/4gl/etc at the same time? >I know that 4.10 is not the current version of the 4gl (is 4.12 the current >version?). In the best consultative fashion, the answer is "Yes, and No". 4.1x (and, where relevant 5.0x) applications do not have to be upgraded to use the new connectivitiy mechanisms provided by 6.00 and 7.00 servers, but the SQLEXEC environment variable will need to be set to "sqlrm" to connect at all. However, using the relay module imposes an overhead compared with a direct 6.00/7.00 connection, so you would get better performance out of upgrading the application software. So, No, you don't have to, but Yes, you'd be well advised to do so. You then get to the thorny part: 6.00 Unix Tools are due out in May 94 (or thereabouts). As yet there are no plans for a 7.00 Tools version, but the 6.00 Tools should work quite happily with the 7.00 Servers, with one known exception. There are significant changes to be made to PERFORM before it will work with with 7.00 fragmented tables -- basically, the ROWID technique it currently uses requires the fragmented tables to be extended to contain a physical ROWID column, and this assumes that ISQL won't be confused by having some tables (non-fragmented ones) with virtual ROWID columns (as in all previous servers), and some with actual ROWID columns (modified fragmented tables). And it won't work at all with unmodified fragmented tables. As a statement of possible future direction, if ISQL has a long term future, then PERFORM may be revised so that instead of using ROWID, it will use one of the unique indexes defined on the table -- possibly the index associated with the primary key, or a unique index associated with a unique constraint, or with some other unique index defined by the user. And it may end up declining to run against tables without any unique index. Further, it might warn at compile time and complain at run time that there is no unique index for it to use. This change is unlikely to happen in 1994. Applications written using ROWID will cease to work reliably on 7.00 Servers when tables are fragmented -- you have just been warned if you hadn't already heard. As far as I understand it, if you don't use fragmented tables, ROWIDs continue to work as in earlier versions. The reason for the problem is that ROWID ceases to be a unique identifier for a row -- ROWID is unique with in a dbspace, but when the table is fragmented across multiple dbspaces, there may be several rows with the same ROWID in different fragments of the table. You should think in terms of ensuring that there is a unique index on your tables for your programs to use instead of ROWID if they do depend on ROWID. You may be able to add a SERIAL column to any table without one yet; any table already with one has a unique index you can use (or should have; if it doesn't, that's your problem!). Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>