[EMAIL PROTECTED] wrote:
In a message dated 5/18/2005 11:50:38 PM Pacific Daylight Time, [EMAIL PROTECTED]
writes:
OK, sure. But readnext doesn't really work on an array but on a select
list.
Ah but that's not so.
You can SELECT myVAR
You can SELECT myVAR to LIST5
You can SELECT myVAR
In a message dated 5/20/2005 2:47:20 AM Pacific Daylight Time, [EMAIL
PROTECTED]
writes:
myVar = 1:@FM:2
SELECT myVar
myVar1 = 3
READNEXT X THEN PRINT X
Right but that's easy to fix.
Instead of SELECT myVar
Use SELECT myVar to myListVar or
SELECT myVar to 3
And then instead of
[EMAIL PROTECTED] wrote:
In a message dated 5/18/2005 2:16:35 AM Pacific Daylight Time, [EMAIL PROTECTED]
writes:
Well it already needs both variables in the 'sequential' access too !
How would it even know that the access is for the next atrribute if it
didn't keep track of the index?
--
In a message dated 5/18/2005 11:50:38 PM Pacific Daylight Time, [EMAIL
PROTECTED]
writes:
OK, sure. But readnext doesn't really work on an array but on a select
list.
Ah but that's not so.
You can SELECT myVAR
You can SELECT myVAR to LIST5
You can SELECT myVAR to MyLIST
and then you
I was told once that was the case in rel 8, but that is unverified. I
wonder if there is some way we could write a test to check that out?
--
Regards,
Clif
On May 17, 2005, at 10:18 PM, [EMAIL PROTECTED] wrote:
And then I would wonder if the code is optimized to actually try to
determine
I think one of the the things that we are overlooking is the underlying
philosophy that machine cycles are cheap, and anything that cuts
development or modification time is a Good Thing. You and I may not
agree with that philosophy (having been victimized by code that took
the idea to it's
[EMAIL PROTECTED] wrote:
In a message dated 5/16/2005 5:00:45 AM Pacific Daylight Time, [EMAIL PROTECTED]
writes:
Yes. But it only works when stepping through an array in a READNEXT
fashion. So if you're accessing fields in random order (as a lot of my
code does) you gain nothing.
All,
Please watch the overquoting. It is very hard on digest readers and
on dial-up connections.
- Charles Barouch, Moderator U2UG
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
the drain
- Montgomery Scott NCC-1701
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, May 18, 2005 3:00 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] I'm in an Array quandry, any suggestions...
I think one
[EMAIL PROTECTED] wrote:
Dimensioned vs Dynamic--brain damaged code is still brain damaged code.
I could not agree more!
the music majors passing themselves off as Pick programmers
For the record I almost failed music history :)
For those keeping track of suggestions for IBM
Allow re-dimensioning of dimensioned arrays at runtime. In VB you have
the REDIM command and in C you can re-dimension damn near anything.
Having this capability would provide the best of both worlds.
It already can!
You either need to use Ideal, Information or PI/open flavour or you need to
...Allow re-dimensioning of dimensioned arrays at runtime...
As others have pointed out, YOU CAN
$OPTIONS -STATIC.DIM
Minus sign means not as in not static dim as in you can redimension
this on the fly at runtime.
It is necessary in Pick- Reality-flavors.
PI- and Ideal-flavors have that
(from memory, so verify via HELP)
$OPTIONS -STATIC.DIM
On May 18, 2005, at 7:15 AM, [EMAIL PROTECTED] wrote:
Allow re-dimensioning of dimensioned arrays at runtime. In VB you
have
the REDIM command and in C you can re-dimension damn near anything.
Having this capability would provide the best of
In a message dated 5/18/2005 2:16:35 AM Pacific Daylight Time, [EMAIL
PROTECTED]
writes:
Well it already needs both variables in the 'sequential' access too !
How would it even know that the access is for the next atrribute if it
didn't keep track of the index?
-- mats
Because
it is to stop up the drain
- Montgomery Scott NCC-1701
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, May 18, 2005 10:15 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Larry Hiscock
Sent: Friday, May 13, 2005 5:57 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
Richard Taylor wrote:
Certainly not enough to justify throwing away one of the
best features
In a message dated 5/16/2005 5:00:45 AM Pacific Daylight Time, [EMAIL
PROTECTED]
writes:
Yes. But it only works when stepping through an array in a READNEXT
fashion. So if you're accessing fields in random order (as a lot of my
code does) you gain nothing.
No it does work even when
Will Johnson postulated:
This would imply that not only would the run-time engine have
to maintain a pointer to the last cell referenced, but also
it would have to maintain a register telling it the cell
number of this cell (not just its offset). So it needs two
variables. I've never heard
In a message dated 5/17/2005 7:47:46 PM Pacific Daylight Time,
[EMAIL PROTECTED] writes:
es, Will. There are two variables. The descriptor definition found in
$UVHOME/gcidir/include/DATUM.h states:
structDstring
{ /* This are my comments. GI */
STRING str;
Anthony W. Youngman wrote:
In message [EMAIL PROTECTED], Roger Glenfield
[EMAIL PROTECTED] writes
Payback during 2nd generation Pick was 10-20 attributes. Back then,
the problem was to not oversize because it slowed down the
read/writing of the blank attributes.
Didn't we hear/read recently
Charles Stevenson says:
[snipped a bunch of good stuff]
If you have a program that manipulates many attributes many times, then
it makes sense to matread them into a dimensioned array up front, and
matwrite them in the end, thereby limiting big string manipulations.
People forget or newbies don't
In message [EMAIL PROTECTED], Roger Glenfield
[EMAIL PROTECTED] writes
Payback during 2nd generation Pick was 10-20 attributes. Back then,
the problem was to not oversize because it slowed down the read/writing
of the blank attributes.
Didn't we hear/read recently that the new compiler and/or
In message [EMAIL PROTECTED],
Richard Taylor [EMAIL PROTECTED] writes
We are faced with this same situation and the thought behind this truly
baffles me. Why take a flexible, dynamic database system and force it to
be fixed length. This is what you are doing using dimensioned arrays and
In message [EMAIL PROTECTED],
Richard Taylor [EMAIL PROTECTED] writes
Yes I have compared the performance. Within the ERP system I worked in we
saw little difference. Yes dimensioned arrays MAY have some advantage
under certain circumstances, but reading and accessing fields in a record
is not
] On Behalf Of George Gallen
Sent: 12 May 2005 16:01
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
WOW. I just found an interesting feature of UV.
You can MATREAD a record that has more fields than are dimensioned,
and you can MATWRITE
, 2005 1:46 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
Sometimes, REC0 returns the entire string too. I ran into this once
converting a program that actively used the assumption that REC0 would
return nothing. Having REC(0) reserved for overflow
We are faced with this same situation and the thought behind this truly
baffles me. Why take a flexible, dynamic database system and force it to
be fixed length. This is what you are doing using dimensioned arrays and
MATREADs. The most common justification I have heard is performance and
this
It really matters what flavor you're running.
Which nobody has explained :-)
Basic Ref for MATREAD says:
If the number of elements in array is greater than the number of fields
in the
record, the extra elements in array are assigned empty string values. If
thenumber of fields in the record is
Richard Taylor [EMAIL PROTECTED] wrote on 05/13/2005 02:05:51 PM:
... Why take a flexible, dynamic database system and force it to
be fixed length. This is what you are doing using dimensioned arrays
and
MATREADs. The most common justification I have heard is performance and
this simply
Timothy Snyder wrote:
Richard Taylor [EMAIL PROTECTED] wrote on 05/13/2005 02:05:51 PM:
... Why take a flexible, dynamic database system and force it to
be fixed length. This is what you are doing using dimensioned arrays
and
MATREADs. The most common justification I have heard is
Maybe the Smart People on this list can give a good rule of thumb for
deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all these
years, I still don't have one.
From: Richard Taylor
We are faced with this same situation and the thought behind this
truly baffles me.
I will admit to
] On Behalf Of Stevenson,
Charles
Sent: Friday, May 13, 2005 1:50 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
Maybe the Smart People on this list can give a good rule of thumb for
deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all
up the drain
- Montgomery Scott NCC-1701
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, May 13, 2005 2:54 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
Richard Taylor
in an Array quandry, any suggestions...
Have you ever compared performance between dynamic and dimensioned
arrays,
or are you just saying that you've never notice problems but have never
tried dimensioned arrays? I've seen it make a HUGE difference in Pick,
UniVerse, and UniData. If you reference many
Richard Taylor wrote:
Certainly not enough to justify throwing away one of the
best features of the Pick database, or having to code
work-arounds to deal with the short-comings of dimensioned
arrays.
I'm maintaining a system that was originally developed on Prime Information
in the
Scott Ballinger [EMAIL PROTECTED] wrote on 05/13/2005 05:10:49 PM:
In UV at least (not sure about UD) attribute processing has improved
dramatically since the old days, to the point where it is essentially
instant.
When you're going sequentially through a dynamic array, that is true.
Change
WOW. I just found an interesting feature of UV.
You can MATREAD a record that has more fields than are dimensioned,
and you can MATWRITE that record back out INTACT without getting an error,
It only bombs with an out of bounds error when you try to reference a
subscript
past the dimension.
While you're at it, move the DIM to a file to be included in all the
programs that use it. Then when you need to change it again in the
future, it's in 1 place. Also create a compile list program that
includes all of the programs that use it as well. After you change the
include file to resize the
I found that problem in the RESULTS or older application where most data
records were dim'd to (100). The original file sizes were around 50-70
attributes and it appeared to have some room for growth. Since it was
written in 1980-82, there has been some opportunity for growth.
Some of my
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of George Gallen
Sent: 12 May 2005 16:01
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
WOW. I just found an interesting feature of UV.
You can MATREAD a record that has
And not
MYARRAY(5) = newvalue
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of George Gallen
Sent: Thursday, May 12, 2005 11:01 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
WOW. I just found an interesting
Shouldn't be a problem as long as you aren't passing the arrays back and
forth between the programs, then they would all need to be dimensioned
the same.
-Dianne
George Gallen wrote:
WOW. I just found an interesting feature of UV.
You can MATREAD a record that has more fields than are
-users@listserver.u2ug.org
Cc: George Gallen
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
Watch Out!!!
If your program changes the last dimensioned field, you will lose the
extra data!!! IIRC, the extra fields are being appended to the last
dimensioned element. If you change
table. It
makes these changes easy. One include to amend and a list of programs to
compile.
Les
-Original Message-
From: George Gallen [mailto:[EMAIL PROTECTED]
Sent: 12 May 2005 16:01
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
WOW. I
element.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of George Gallen
Sent: Thursday, May 12, 2005 10:01 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
WOW. I just found an interesting feature of UV.
You can
The extra fields get put into element (0) of the array as a dynamic
array, should you want to access them.
--
Regards,
Clif
~~~
W. Clifton Oliver, CCP
CLIFTON OLIVER ASSOCIATES
Tel: +1 619 460 5678Web: www.oliver.com
progamming in VB.
My 1 cent.
- Original Message -
From: George Gallen [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, May 12, 2005 12:04 PM
Subject: RE: [U2] I'm in an Array quandry, any suggestions...
OK. ours is being stored in element zero. None of the programming use
You may want to think about this again if you think you will ever move to
.NET as OPTION BASE 1 is gone. Everything starts at '0' now.
Regards,
Jim
[snip]
I use OPTION BASE 1 to keep my head on straight when progamming in VB.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To
That's nice to know. I've inherited some VB code written with OPTION BASE 0
and it keeps me honest.
Thanks.
- Original Message -
From: James Canale, Jr. [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, May 12, 2005 1:16 PM
Subject: RE: [U2] I'm in an Array quandry, any
49 matches
Mail list logo
