I'm planning to actually code (!) in openQM and UniData beginning in
January. I'm doing design and experimenting now. In case you think
I'm an old pickie and this should be a piece of cake for me, I'll
confess that until now I have always had teams of people working for me
in the pick arena, so I don't know what most pick developers know. (I
did my time in heads-down development a coupla decades ago in CICS
COBOL.)

So now I have some very basic (no pun intended) questions, starting
with this one.

I have worked with a UniData product that has long text fields (such as
comment fields) as multvalued with formats like 60T. If I want to
pass the text as a full string without any value marks, I could replace
the value marks with a space, but I would think I could define a long
single-valued field instead to eliminate the need for that.

1. I haven't looked it up for any particular db, but is there a
standard longest field across pick environments? (An actual dtabase
storage restriction)

I would like the database to work in openQM and UniData, but would also
like it to be compatible with the others -- UniVerse, Revelation,
jBASE, D3, UniVision if I ever made the application work with those.

2. I realize the FMT is for display, not storage size, but is there a
maximum in the FMT in the dictionary, such as FMT(99999T)?

3. Are there performance implications if I make a long single-valued
text field instead of multivalued short lines of text? Other
implications?

4. These questions might not even be the right ones, so what do you
consider to be "best practices" related to long text fields in an MV
environment where the application code will be in languages other than
DataBASIC (e.g. PHP), retrieving data using a dictionary definition.

Thanks in advance for any help. --dawn

dawn wrote:

I want to live "in theory". Everything works there.

lol.

--
Kevin Powick

Dawn,

When you describe your LONG text fields as 60T, you mean 60 characters
long that automatically folds - (on display) at a convenient and appropriate
space, right ? You don't mean 60 terrabytes.

60 characters is not very long. I support an application that routinely
passes
a large dynamic array to subroutines to append additional lines of specially
formatted text for a report. The author has limited this array to a maximum
of 1000 lines for some reason. Not sure why. Maybe performance.

I often pass some data to a subroutine that might or might not have
value or sub-value marks. It might even have attribute marks. I've never
had a problem passing arrays of any size. I know the first time I worked on
a very large dynamic array on AP-PRO, it took a lot of time to process
the array since I was extracting a value then deleting it then extracting
another
value and so on. Searches of long arrays were very slow. The delete was
even slower.

I don't know what sort of thing you are trying to accomplish, but it's
common
for me to write a program that creates a very text file that I separate the
fields
with tabs and I sometimes embed EXCEL formulas in the fields. When Excel
opens the file, it will interpret the formulas as though they were entered.

I've even written programs to develop web pages, but I've never published
them
directly to a browser, I always write them to a DOS file and use them that
way.

I took COBOL in college long ago. I even worked on some COBOL programs
when I worked at NCR back in the stone age. Before this, shortly after I
got out
of the USMC, I applied for a job at a VOLT agency in Phoenix. The contact
there
was talking about COBALT this and COBALT that. I knew the difference,
but since I figured he was just stupid, I did not see the need to correct
him.

I should have corrected him since he used that lack as a reason to state
that
I did not know COBOL if I could not even say the name properly.

Oh well, I guess the age of being considerate was over about then.

Larry

Here are the QM answers....

dawn wrote:
QM will support strings up to 2Gb throughout. Of course, you probably
run out of other resources before you hit this limit.

As an aid to cross-platform portability, QM always sets a define token
named QM. Thus you can insert code such as
$ifdef QM
...qm stuff...
$else
... non-qm stuff...
$endif

How nice it would be if the other vendors did this too.


Contrary to its general design policy, QM does impose a limit here of
4096 characters. If someone came up with a realistic reason to want
this to be bigger, I'm sure we would do it.

This all depends what you are trying to do. A bit more information
would help. Mutlivalueness (new word) is usually determined by the
nature of the data, not some arbitary string length consideration.

An explanation of what this long data represents would be useful.


Martin Phillips, Ladybridge Systems.

Kevin Powick wrote:
"In theory" is an entirely different subject. I live there when
teaching and researching, but if you have a team responsible for
developing software you cannot live "in theory". You live by
delegating -- giving up control, while being more accountable for
success than if you were a developer.

In the past in the pick world (not Java) I have put theory and research
into practice with a team where right now I'm back to hands-on, but for
the first time flying solo with pick.

It would be a mistake to suggest that I haven't been battered and
shaped by reality as much as any other software development
professional. I can only live in the clouds for a few months at a time
before I code and this time I'm not picking up MySQL, but openQM, for
example. --dawn

Homer L. Hazel wrote:
Correct -- I am referring to the text justification "T"

My question is whether to make an array of lines, which is what I have
seen in the pick apps I've worked with, or, preferably, permit the full
text of a (possibly marked up) document to be included in a single text
field. Since there really is only one value for the text field, I
would prefer not to use the technique of having a multivalued text
field for the comment.

nice

good story. --dawn

None wrote:
Yes, that is excellent. I won't come close.

I agree. And of course I'd also like that standard data source
definition and connectivity for use with all client-server access
across all flavors and within all languages. ;-)

That's too small for the field, but I can start with that.

I don't know enough to know my options yet. Thanks.

Yes, I agree. The text is all a single "script" as in the "script" of
a 30-minute TV show (for lack of better term -- more information once I
have the design complete). My original thinking was to handle these
documents using XML at the file system and simply store a URL. But I
want to consider queries against this data as well as the other that is
stored, which is why I would like to store it in the database.

After I think about it a bit more, I might catch you offline on that,
but if you think of it as scripts as indicated above it will give you
an idea of the nature and length of the data.

Thanks a bunch. --dawn

Hi Dawn,
I don't know whether this will help you or not, but in UniVerse, if I have a
long comment-type field, I have the user enter it in something like Notepad
(or read it in line-by-line from some file using READSEQ), then WRITESEQ the
data out to a uniquely-named file somwhere on the system, and store that
filename in the database.

Then, when I want to read it in again (for display or other functions), I
open the file and, using READSEQ, read it in line-by-line. I have a
subroutine as well that I can use to split/combine lines based on a
separator character(s) within the file (CHAR(254), CHAR(13),
CHAR(10):CHAR(13) combination, or whatever character(s) you want). The
subroutine can also work like the "T" format, separating lines at a
convenient place close to X characters and inserting a separator character.

Dave


"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Hi Dawn
I have enjoyed your input to the group immensely.
The 60 characters is undoubtedly some programmer just chopping the green
screen entry into convenient size display fields.
It actually fights the "T" dictionary which trys to split the fields based
on a convenient space in conjunction with the screen terminal size
definition.
There are no practical limits on string size.
Peter McMurray
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Hi Dawn.

I tried to download OpenQM this evening to try on my Windows XP laptop.
Unfortunately it seems that my anti-virus software detects a Back-Door
Trojan and refused the download.

Pity as I was keen to take a look at OpenQM too. I assume this product
is genuine?


John

dawn wrote: