Re: INFORMIX programming help NEEDED

->From: Forrest Aldrich <visgraph!forrie> ->Subject: INFORMIX programming help NEEDED ->To: informix-list@rmy.emory.edu ->Date: Mon, 10 May 1993 18:45:38 -0400 (EDT) -> ->After much research, within my given limitations (such as proper reference, ->etc.) I would appreciate the help or advice from the net on the following ->issue: -> ->I have (or will have soon) an address/telephone number database. This ->database includes business associates as well as personal entries. Because ->of the activity I have on the phone, I have found it _exceedingly_ important ->to take notes during the phone calls; however, I've no really decent PAPER ->way to manage or organize these notes. So I had an idea... -> ->I would like to develop a take-notes-on-call function from within Informix, ->which would enable me to enter (at a variable length) notes on a given ->phone call, and perhaps cross-reference them if need be. [1] -> ->(I have access to Informix-SE and ONLINE... ONLINE seems to be a lot of ->overhead, however) [2] -> ->The concept I visualized was something like this: -> -> - For each note entry, there would be a 'header' (via another table or -> what have you) which would contain information such as who entered -> the note, the date and time, keywords (for cross ref?), and a SERIAL -> ref ID. [3] -> -> - Each person/associate would have notes in their own separate file. [4] -> -> - Each entry/note would be of a variable length. [5] -> ->It was suggested that I use BLOBS for this. However, due to some of the ->(strange) limitations of BLOBS, I disagree. For one, you can't include ->them in an array, so that eliminates the crossref funtionality that i ->wanted. Being relatively unfamiliar with BLOBS, some of it sounded ->rather obtuse to me anyways. -> ->The only reason, that I can see, to use ONLINE would be for BLOBS. [6] -> ->The other way I though of would be to have each entry/note be stored ->in its own file. The filename would contain certain identifying information ->that could be used by the program (ESQL-C?) to identify and find it. There ->could be a separate table for the corresponding headers... it sounds like ->a MESS! :) [7] -> ->Has anyone experience with this sort of thing? Can someone help, or provide ->suggestions/examples of how to go about this effectively? The need for ->this is great... ie, I should have had this yesterday... -> ->One other thing I thought to do would be to include a digitized image in ->the database (for each entry) that would contain something like the ->business card, or even perhaps a photo of the person. This, I understand, ->could be accomplished with a graphic-BLOB (again, how I am unsure). Or ->I could hack in an external (yeck) program through ESQL-C. [8] -> ->I hope I have provided enough information. If there are other questions ->about this, I will do my best to clarify things. -> ->Thanks in advance for any help. -> ->Forrest Aldrich -> The following items use the reference marks [#] that I placed in your msg: [1,2,6] If this is the bulk of your application, you don't need OnLine. SE is easier to administer and appears to be adequate for your needs. [4,5,7] Instead of storing your notes in one or more files, perhaps you should use a table like the following: CREATE TABLE note_text ( ref_id INTEGER NOT NULL { reference to header table in [3] } , sequence SMALLINT NOT NULL { keeps lines in order } , text_line CHAR(80) NOT NULL { individual line of note text } ) The 'take-notes-on-call function' you describe in [1] should deal with the details of word wrap, ease of editing, etc. By the time the database sees it, a note is merely a sequence of lines of text. Obviously adjust 80 to be the appropriate line length for your application. If you want to ensure a little more privacy for the notes, include the associate's login id in the note_text table, and only allow users to view notes having their own login id in the indicated field. Use INTEGER for sequence, if 32,767 lines of text per note is not enough. [8] If your scanned images are large, then you might need BLOBs and hence OnLine. Alternatively, store the image in a file, and the file name in the database. We have used the latter technique for engineering drawings produced via AutoCAD and similar products. IF you can GUARANTEE that the scanned images will be small enough, you could fool the system and put them in a CHAR data field. Maximum size of CHAR is 32,511 bytes, which is not much of a scanned image. Then you would need to pass this long CHAR variable to some sort of display function, but not try to do other manipulations with it. In summary, item [8] seems to be the determiner as to whether you need OnLine or not. If you do go with OnLine, you should revisit using TEXT (one of the BLOB types) for your notes. Someone who knows more about using BLOBs than I do needs to advise you on this. Regards, Alan +------------------------------+---------------------------------------+ | R. Alan Popiel | Internet: alan@den.mmc.com | | Martin Marietta, LSC | ( Please note: My opinions do not ) | | P.O. Box 179, M/S 5422 | ( represent official Martin policy. ) | | Denver, Colorado 80201-0179 | Voice: 303-977-9998 | +------------------------------+---------------------------------------+