glennr@holin.ATT.COM (Glenn Robitaille) (11/29/88)
Has anyone out there converted from the standard Informix back end to the Turbo? If so, how hard was it and how is it done? Any compatability problems with your front ends running with a new back end? Also, does anyone have any complaints/concerns/problems with Informix that would be of use to me. I am writing a document for a group to help them base a DBMS decision on. Finally, how is Informix support? Is it timely? Are their fixes reliable, or do they have poor quality control? Thanks for any help on any of these issues. Glenn Robitaille AT&T Bell Labs HO 2J-207 att!holin!glennr (201) 949-7811
jsh0@isg300.UUCP (News Administrator) (12/01/88)
In article <257@holin.ATT.COM> glennr@holin.ATT.COM (Glenn Robitaille) writes: > >Has anyone out there converted from the standard Informix back >end to the Turbo? If so, how hard was it and how is it done? Our first conversion used no locking and did not use transaction logging. In this case the process was as simple as changing SQLEXEC so that it pointed to the Turbo backend (SQLEXEC=$INFORMIXDIR/lib/sqlturbo). The second conversion used both of the features mentioned above but had been written originally with the Turbo product in mind (before it was available for the AT&T machines). Because of coding practices this changeover went smoothly but some of the code did have to be modified because of the added functionality of the Turbo product (E-Mail me for details). >Also, does anyone have any complaints/concerns/problems with >Informix that would be of use to me. I am writing a document >for a group to help them base a DBMS decision on. > >Finally, how is Informix support? Is it timely? Are their >fixes reliable, or do they have poor quality control? > With respect to the above once you get to know some of the techs and earn their respect they are wonderful to work with in all respects that you mention above. We have been using the product line now for years and it has consistently gotten better. Along with this improvement in the product the support has gotten better also. I highly recommend the product. -- J. Steven Harrison VP Technical Services Information Systems Group Inc., San Diego, CA (619) 234-3405 x274 {nitro, ucsdhub!jack}!isg100!jsh0
rick@jpusa1.UUCP (Rick Mills) (10/04/89)
I have Informix 4GL 1.10 Rev A and a question...
I would like to declare a scrolling cursor to select
a list of rows for a screen form. I want the ability to do a
Next-Previous with these rows, and update selectively as I go.
Is this possible without declaring a second cursor to
keep track of where I'm at in the list? Shouldn't this be easy?
I know that I have to reopen the cursor to realize any
updates I've made underneath the nose of the current one, but
then I start back at the beginning of the list...
I'm sure someone has wrestled with this one before -
Any help would be appreciated...
Once again I apologize for the Informix specific question,
and I admit that I'm somewhat spoiled by the wealth of good advice
here on the net!
-Rick
--
Rick Mills {gargoyle.uchicago.edu,uunet.uu.net,spl1,ddsw1}!jpusa1.uucp!rickwalt@hisata.UUCP (Walt Hultgren) (10/06/89)
In article <1178@jpusa1.UUCP> rick@jpusa1.UUCP (Rick Mills) writes: > > I have Informix 4GL 1.10 Rev A and a question... > > I would like to declare a scrolling cursor to select >a list of rows for a screen form. I want the ability to do a >Next-Previous with these rows, and update selectively as I go. > Is this possible without declaring a second cursor to >keep track of where I'm at in the list? Shouldn't this be easy? Here's the best solution I've found so far. Use three cursors for each table (or logical group of tables) that you want to query and update. The first cursor is the one that is prepared and declared "on the fly" based on the where text obtained from a construct statement. For this cursor, don't select all of the fields you want from the row, but only enough to uniquely identify one row. As an example, suppose you have a table of invoices called "inv". Each row can be uniquely identified by an invoice number "inv.numb". In this first cursor, don't say "select * from inv", say "select numb from inv". Define a variable in your I4GL program to hold the "current" invoice number; e. g., "cur_inv_numb". To navigate the rows returned by the user's query, fetch the prepared cursor into cur_inv_numb. The two other cursors are used to fetch the entire row from inv for the current invoice number and are declared in the program source. One is used for inspecting rows and the other is used to delete or update rows. These declarations might look like: declare inv_nolock cursor for select * from inv where inv.numb = cur_inv_numb declare inv_lock cursor for select * from inv where inv.numb = cur_inv_numb for update For menu selections like Next, Previous, etc., do the appropriate fetch with the query cursor, followed immediately by: fetch inv_nolock into pr_inv.* where pr_inv is the "program record" corresponding to a row of inv. This will show the user the current contents of the row, not just the contents of the row at the time the scroll cursor was opened. For a Delete or Update, first do a fetch inv_lock into pr_inv.* then display the row. This shows the user the guaranteed current contents of the row and locks it. You can then update or delete the row using a "where current of inv_lock" clause. Close inv_lock immediately after the update or delete. An alternate way of doing things is to use ROWID instead of a unique data value. Whether or not this is appropriate will depend on your application. This method will not automatically include added rows to the current user selection like Informix 3.3 did. I wish I knew a clever way to do this. Everything I've thought of so far involves a lot of overhead. Any ideas, anyone? Walt. Walt Hultgren Hultgren Information Systems, P. O. Box 386, Tucker, Georgia 30085 USA Voice: +1 404 564 4707 UUCP: ...!{most_backbones}!gatech!hisata!walt
emuleomo@yes.rutgers.edu (Emuleomo) (10/07/89)
In article <1178@jpusa1.UUCP>, rick@jpusa1.UUCP (Rick Mills) writes: > > I have Informix 4GL 1.10 Rev A and a question... > > I would like to declare a scrolling cursor to select > a list of rows for a screen form. I want the ability to do a > Next-Previous with these rows, and update selectively as I go. > Is this possible without declaring a second cursor to > keep track of where I'm at in the list? Shouldn't this be easy? I had this same problem some time ago trying to port a Foxbase application to Informix. The trick I used was to declare 2 cursors. The 1st one a SCROLL cursor that will be used to retrieve the **SERIAL NUMBERS** of the records you need. The 2nd cursor will be used to select ONLY ONE record; i.e. the record that matches the current serial number!! Furthermore, this 2nd cursor will be declared *for update*. Now you can do NEXT, PREVIOUS, LAST etc.. on the SCROLL cursor and whenever you need to update the current record, all you need to do is fire off the *update* cursor!! This worked quite well and in the application I wrote. Watch out for records in the *active set* of the scroll cursor that may have been deleted. My approach was to inform the user that the record has JUST been deleted!! Hpoe this helps. --Emuleomo O.O. (emuleomo@yes.rutgers.edu) -- ** Writing error-free code MUST be magic! Why else is it sooo difficult to do?
bob@sequoia.UUCP (Bob Kieras) (10/07/89)
In article <1178@jpusa1.UUCP> rick@jpusa1.UUCP (Rick Mills) writes: > > I have Informix 4GL 1.10 Rev A and a question... > > I would like to declare a scrolling cursor to select >a list of rows for a screen form. I want the ability to do a >Next-Previous with these rows, and update selectively as I go. > Is this possible without declaring a second cursor to >keep track of where I'm at in the list? Shouldn't this be easy? > I know that I have to reopen the cursor to realize any >updates I've made underneath the nose of the current one, but >then I start back at the beginning of the list... > I'm sure someone has wrestled with this one before - >Any help would be appreciated... Rick, I too wanted this sort of update as you go. This is how I solved the problem. When the user picks a record for update, the 4gl program first stores the rowid for that record. The record is then updated with an update sql statement like " Update xtabel set xxx= yyyy where rowid = stored_rowid". Then the cursor is closed and reopened. A while loop is used to position the cursor back to the record that was updated again by matching the rowid with the stored rowid. Then the updated record is displayed for review. This solution is brute force. It would grind too much if the cursor returned too many records and the record updated was the 500th one. In my case, the records to be scanned for update were already limited to a small number by the query the cursor was using. Hope this helps, Bob Kieras (usual disclaimer stuff)
daveb@elaited.i88.isc.com (Dave Burton) (10/13/89)
In article <1178@jpusa1.UUCP>, rick@jpusa1.UUCP (Rick Mills) writes: | I have Informix 4GL 1.10 Rev A and a question... | I would like to declare a scrolling cursor to select | a list of rows for a screen form. I want the ability to do a | Next-Previous with these rows, and update selectively as I go. | Is this possible without declaring a second cursor to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | keep track of where I'm at in the list? Shouldn't this be easy? In article <Oct.6.13.15.16.1989.2676@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: |The trick I used was to declare 2 cursors. The 1st one a SCROLL cursor ^^^^^^^^^^^^^^^^^ |that will be used to retrieve the **SERIAL NUMBERS** of the records you |need. The 2nd cursor will be used to select ONLY ONE record; i.e. the |record that matches the current serial number!! Furthermore, this 2nd cursor |will be declared *for update*. |Now you can do NEXT, PREVIOUS, LAST etc.. on the SCROLL cursor and |whenever you need to update the current record, all you need to do |is fire off the *update* cursor!! ... |Watch out for records in the *active set* of the scroll cursor |that may have been deleted. My approach was to inform the user that |the record has JUST been deleted!! My solution to this problem, ugly as it is, is to open a single scroll cursor for the selected rows, then next/previous/etc as desired. Updating and deleting presents a problem in that the active set is *not* updated after an update or delete operation. Because it was vital for my client to see the changes in the active set, I had to code the update and delete functions so they would: get the unique key of the current row (or the next or previous key for deletes) do the operation close the set open the set fetch until the keys matched This allows the next/previous stuff to function as before, and the active set to reflect the "actual" state of the database. The problem areas with this approach are twofold: 1) if the last row is deleted, what can be fetched? 2) if another user is working with the same table, is the active set an accurate picture of the table? Probably this is a poor solution to this problem, but I know of no other that works as well in most cases (I'm not usually faced with problem 2 in practice, and problem 1 may be dealt with by aborting the query after the last delete). I'm inclined to call this a problem with Informix 4GL - I want accuracy before performance, and I want performance, but the active set stuff prevents this. -- Dave Burton uunet!ism780c!laidbak!daveb