Re: Help With BLOBs, General Informix Comments

In article <2lnsus$7o7@emory.mathcs.emory.edu>, Jack Parker <jparker@hpbs3645.boi.hp.com> wrote: >} 1) You can not use standard record assignments when the record >} contains a BLOB. >} >} LET rec1.* = rec2.* > >Pain isn't it? Yes, it is. What is the commonly used method of performing this function, since it is not built in to the 4GL? (This is my first program using BLOBs) >} >} 2) You can not use standard assignments of any kind on BLOBs. >} >} LET rec1.textblob = "This is the new contents of BLOB" >} >} Back to the "too complex" error again. > >Also a pain. Same question, how do you do it? Are there any C functions that people can part with which will let me do this? >} 4) You can't even use the multiline text editor to edit a TEXT field. >} This seems like a rediculously blinding oversight. Instead of >} allowing a user to simply enter a "Notes:" field with a simple, >} right there on the screen field, they have to press "!" (intuitive) >} run another program (which they must now be taught how to use), >} exit it, and return to the screen to see all or part of a simple >} text message with "?" marks in it. > >Well - you DO get an error message saying: > "Use "!" to edit text and byte fields". Darned nice of 'em, doncha think? >} 5) [4GL Issue] There is no support for multi-screen forms, as there >} was in ISQL. The lack of multiscreen forms puts a *SERIOUS* >} burden on the programmer when dealing with records with more then >} just a few fields, and is a tragic oversight. > >Disagree - you are no longer in that environment. When you need a second >screen do it with program control. Yes you do need to do 2 input statements >but if you've got that much information for one form then you may be >overwhelming the user and your database may be well served by normalization. I was hoping that the form engine could tell what field you were in, and make sure that the screen that the field is on would be automatically brought on-screen. As a programmer, this sounds like it would be a very simple function to implement. The problem is not just that you need 2 input statements, but that you then need to allow for arrowkeys and tabbing between forms, trying to make it look like a smooth implementation. Instead you have to juggle forms and control variables in BEFORE INPUT's in order to correctly position the cursor when a user goes, for example, from the first field on Page 2 to the last field on page one. It is not much work to do this in the 4GL libraries. Much less than to recode this type of functionality in each module for each multiscreen form. >} 6) [4GL Issue] It is impossible to use arrays of such structures as >} WINDOW and CURSOR variables in a program. The inability to make >} an array of window variables makes it necessary to use lengthy >} CASE statements in order to switch between active windows, >} instead of simply being able to use something like: >} >} CURRENT WINDOW IS winarray[winnum] > >Agreed. > >} 7) [Forms Issue] There is no support for scrollable fields, or even >} the option of opening up the bottom line of the screen, like you >} get with a CONSTRUCT condition in a field smaller than it. This >} requires the form designer to make every field the maximum size >} possible, in the event that the use will need all of it, even if >} the data is usually only a few characters wide. > >You can always (try to) do this programtically. It would be nice, but I think >its a bell/whistle. Of course thats just my $.02. It's a pretty fundamental bell or whistle. Oracle has had this functionality from the earliest versions, as well as Progress, and (I think) DBase. >1) you can try wordwrap on the varchar field, >2) (I haven't tried this) do an autonext in the form, in your input section > do an AFTER FIELD \\ IF LENGTH(field) = max THEN \\ CALL inp_field(field) >3) write your own input code in 'c'. Again, if I can write this code for every application, then why couldn't Informix just build it once into the form engine? A real lack of foresight. >} 8) [Forms/4GL Issue] There is no way to remap the default field >} editor keys (Ctrl-A,D,R,etc) or disable the features if they >} are unwanted. > >I guess I'm so used to them that it doesn't bother me. Unfortunately, I'm writing an application to be used by non- to semi- computer literate govt. employees who don't have time to learn too much, so I have to be able to make things as simple as possible. Not being able to remap or disable these keys prevents me from using memnonic (sp?) keys, such as ^D=Delete Record, ^A=Add Record, etc. >} I am extremely upset with the lack of robustness that a company as >} successful as Informix has put into their Online product, which I've >} gotten the impression they are promoting as their flagship product. > >What specifically do you find not 'robust'? We have been using Online very >successfully. It sounds like most of your criticism is directed at the front >end tool 4GL. You are corrct. I mistakenly complained about Online because I did not have the BLOB frustrations with the Standard Engine, and spoke before I though. Substitute 4GL for Online. Oops! :-( >} The key to a good database application is that people with minimal >} training can use it easily, and that design goal is made much more >} difficult when the engine you are building on does not have such >} basic features as detailed above. > >I think you're opinion of 'basic' is what was 'basic' to the last package >you worked with. I disagree. I think that the complaints are considerable design limitations with the product from the perspective of a developer. The code for opening up the bottom line if the field is larger than the space for it on the screen is already implemented in the code for the CONSTRUCT statements, for example. Why not just put in one more hook to use it with the INPUT statements? These features are also found in most other competitive products (to mu knowledge). >I'm not happy with how BLOB's are handled either - can't query on them is >my peeve - in fact I've gone back to the old key,sequence,text approach. >Still BLOB's are still somewhat new. I'm not familiar with the "key, sequence, text" approach. What is it? (I'll probably recognize it when you describe it ;-) >} If anyone has or knows of workarounds for the above issue, either in >} the public domain/shareware/freeware or commercial, please let me know. - Brian G.