Re: ISQL forms on NT?
Posted in 1997
On 03/11/97 Nils Myklebust wrote: > Joel Robinson <joelatg@netcom.ca> wrote: > > :It seems very reasonable to want a isql on NT. Also with a large number > :of WORKING reports and forms, it would be nice to offer an NT platform > :solution. > : > :Not everyone in this world needs a fully GUI to do data entry and > :reports! > > May be not (or may be they do?), but that was never my intention with > my response. The point is that NT is inherantly GUI although character > based tools are possible. It's inconceivable that anyone would want to > write an ISQL emulating tool for NT, and even less conceivable that > Informix would port it. After all it's an old toolkit whose time has > passed years ago. Additionally it would have to run not only on the > Windows NT machine where the database is, but also in C/S mode on MS > Windows workstations. Quite inconceivable, unless there are realy a > lot of users out there that want to do this same thing. I doubt that > very much. > > If the original poster wanted to go to NT there can be no alternative > than that they also eventually wants to go with GUI applications. > Their "problem" is that there is no stopgap solution to run ISQL with > the database on Windows NT. > > One thing I haven't realy thought of until now, that they could do, is > of course to continue running ISQL on Unix while the database is on > NT. However I wouldn't do such a thing. Why create so many problem > when there are allready excelent solutions available using Unix on the > server? Then character based and GUI tools can be used at will. That's > my point. > > > Nils.Myklebust@idg.no > NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway > My opinions are those of my company > The Informix FAQ is at http://www.iiug.org > Nils, Perhaps you are missing another point here? A lot of graphics intensive businesses are retiring their old UNIX systems in favor of newer, more powerful, usually less expensive, Intel Pentium (or Pentium Pro) multi- processor systems running Windows NT. The primary focus of these companies is not databases, or database applications, (which historically have been well implemented on single processor multiuser system) but graphics (which historically excel on a multiprocessor single user environment). The fact that most of these graphics intensive applications make use of RDBMS systems was not much of a problem in a UNIX environment, but is becoming a real stumbling block in the Windows NT world. The end users are simply replacing older semi-proprietary UNIX systems with newer "open" systems which they can purchase from a multitude of vendors. Many end users ran an OSF/Motif X Windows "environment" on their UNIX operating system - primarily in a "text within a window" or tty mode rather than a pure GUI mode. Now they are migrating to a Microsoft Windows "environment" on a Windows NT operating system (which looks very similar to the OSF/Motif X Windows "environment" which they where used to). The graphics intensive applications which they run usually create their own window to run in, or are full-screen windowless applications, and the user might not care (or even know) which underlying OS is in use. In a homogeneous environment of non-UNIX platforms it is wonderful to have Informix ESQL/C, ODS, XPS, and IUS available; but it is a tragedy to loose I-SQL, and I-4GL capabilities. The DBMS vendor which makes this migration from UNIX to Windows NT the least painful to the end user will probably win the lion's share of the DBMS software sales in this arena. Informix has done a tremendous job in porting world class dataservers to this environment, but have done very little to support their long time I-SQL, and I-4GL users. I am certainly not trying to make this a UNIX vs Windows NT issue (because I _love_ UNIX); but Windows NT is making a serious entry into even the largest IS departments. Why force legacy customers to search for someone else's DBMS development tools when they already like those from Informix? -- Regards, Walter S. Tyszka (wstyszka@ingr.com) * Standard disclaimers apply *