[U2] Basic vs Execute Select

[Mark Johnson]

A recent thread debated the speed of these 2 SELECT methods.

My question is what would be the preferred way to insure that all records may
be counted for on an active system instead of a dormant system.

Thanks in advance.
Mark Johnson
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Fw: More U2 programming hints

[Debster]

I have usually used a BASIC SELECT within a routine that is grabbing a very
large file during something akin to a overnight/day-end routine where
end-users are not likely to be on the system, or the file is simply utilized
to retain daily processing keys to overnight updating (i.e. a temp file to
retain invoice keys), or off a list that was created within another process,
especially when the same keys are for multi files (i.e history, active
files).   This is especially useful when if you were to attempt to select a
large file that may cause you to wait until next shrove tuesday to be able
to process ityech...index it, or something!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jeff Marcos
Sent: Sunday, October 09, 2005 8:26 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] Fw: More U2 programming hints


I must agree that a BASIC SELECT is quicker but... Don't you run the risk of
missing groups (in the read function) in this type of select? If users are
updating this file they could insert data into a group which you may already
passed.



You would only use this type of select when no one is updating this file.



Regards,

Jeff Marcos



-Original Message-

From: [EMAIL PROTECTED]

[mailto:[EMAIL PROTECTED]
 ] On Behalf Of Mark Johnson

Sent: Thursday, 6 October 2005 10:26 PM

To: u2-users@listserver.u2ug.org

Subject: Re: [U2] Fw: More U2 programming hints





I can't see how a BASIC SELECT can be slower than EXECUTE "SELECT". It

doesn't have to go through to get 'xxx items selected' before it processes

the first one. I also don't believe the mechanical difference once it

begins, ie 'find the next group' etc. Wouldn't you think that this at least

spares the actual hashing as it is navigating through the file sequentially.



I would really like to see a great proof program against BASIC SELECT. I

often replace EXECUTE "SELECT" with a BASIC SELECT over the years *because*

it has always ran faster, regardless of platform. I've had many

opportunities to be proven wrong. I've tested every replacement and have

always reported an improvement.



Thanks.

MarkJohnson

- Original Message -

From: "Allen E. Elwood" <[EMAIL PROTECTED]>

To: 

Sent: Tuesday, October 04, 2005 5:45 PM

Subject: RE: [U2] Fw: More U2 programming hints





> This is the way it was explained to me way back in '88.  The internal
select

> is slower on the whole file, but immediate in response.  It works the same

> as LIST.  If I list a file with 2,000,000 records I get immediate
response.

>

> If I want to process an entire file, then external select is slower on

> response, i.e. I have to wait for 2 million records to be selected  before

> processing begins, but is quicker in processing all records.

>

> The internal is slower due to the system having to stop what it's doing,

> find the next group, break out the individual ID's from that group, and
then

> return it to the program - over and over again as it makes it's way
through

> the file.

>

> hth!

>

> Allen

>

> -Original Message-

> From: [EMAIL PROTECTED]

> [mailto:[EMAIL PROTECTED]
  Behalf Of Stevenson,

> Charles

> Sent: Tuesday, October 04, 2005 14:24

> To: u2-users@listserver.u2ug.org

> Cc: Louis Windsor

> Subject: RE: [U2] Fw: More U2 programming hints

>

>

> This is a bit disconcerting.

> BASIC SELECT should be faster than EXECUTE "SELECT..."

> Maybe the smart people can weigh in on this:

>

> > From: Louis Windsor

> >

> > A few years ago we used the BASIC SELECT FILE as opposed to

> > the EXECUTE "SELECT FILE".

> >

> > We updated UniVerse (don't ask from what version to what

> > version as I don't remember) and overnight ALL our programs

> > ran five or six times longer.

>

> Completely contrary to my experience and counter-intuitive, too.

>

> > We were told (by VMark) that the BASIC SELECT now selected

> > each group but it could be optioned to work the "old" way.

>

> Hmmm, do I vaguely, hazily remember something about that?  Maybe on

 this

> list? Maybe in release notes?  No uvconfig option jumps out at me.

> I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT.

> $OPTIONS FSELECT  would slow the BASIC SELECT down to approximately

 the

> same as EXECUTE "SELECT...",  but not make it slower.

> Louis, do you, perchance, use $OPTIONS FSELECT?  Maybe buried in a

> $include file common to every program?

>

> > I wrote a conversion program to change ALL BASIC SELECTs to

> > executed SELECTs in the source and recompiled and that is the

> > way we have done it ever since.

> >

> > I don't know if things are different now but we have grown to

> > prefer EXECUTEd selects as selection criteria can be included.

>

> Louis, can you run a simple benchmark and see if this is still true?

> Or show us an example of your own?

>

>   INTERNAL:

> OPEN "[really big file]" TO F ELSE STOP

> CRT 

Re: [U2] Programmers and Documenation.

[Jerry Banker]

It also helps in determining if the project was done correctly. Many times 
what is asked for is not heard or partly. If you put it down on paper the 
person that requested the job can read it and if what is written is not what 
they asked for they can let you know before it is released. I know of many 
times that a project was thought to be planned out and thought to have all 
of the ducks in a row but when finished did not do some particular feature.

- Original Message - 
From: "Marilyn Hilb" <[EMAIL PROTECTED]>
To: 
Sent: Monday, October 10, 2005 10:05 AM
Subject: RE: [U2] Programmers and Documenation.


I may not be using the best verbiage.. but I do very much enjoy writing 
documentation. NOT I believe what is called "high-level integrated 
documentation". I think of that as integrating the new features into a very 
large and complex documentation manual on the whole system. "not my job 
mon".

I do enjoy however witting a 'simple' word document incorporating screen 
shots and what I hope to be realistic usage/samples of the feature in the 
terms that the folks in the field would actually relate to.

As a single shop here (not having an additional person to do a final QC of 
the project) I use the documentation phase as a final walkthrough and 
testing of the project. After putting the delivery onto a new file set as 
well, this also insures that I got all the pieces onto the delivery :). 
(yes, no version control here.. lets not get into that discussion again 
please).  In addition I send the documentation to some folks in the field so 
they can approve of the project before it is installed. They often come up 
with good suggestions at that time!

Doing the documentation cycle really helps me get an overall view of the 
project and often during this cycle I come up with additional quick bells 
and whistles that really just pull it all together. Amazing what 
simple/obvious things I see during this phase that I didn't see when working 
deep in the detail. I am very happy that even though this is a small shop, I 
am allowed the time to write up documentation.

Many times I doubt that the folks who use the system give the documentation 
more than a glance.  More than once I get a call asking about the new 
project.. and I answer and 'politely' say.. "it is in the document" and I 
get back "well, I didn't read the documentation".  I grumble under my breath 
and make my voice smile and hang up the phone quickly.

At my previous position where we had a QC team as well as an official 
documentation team, I was still able to write my documentation for the new 
features only and it was their job to incorporate it into the big manual. 
Worked for me :).  They would also review it (in the cases where it was pure 
custom and did not go into the manual) and proof it for verbiage etc to make 
it a bit more professional sounding. The thing I didn't like about this is 
the folks who did the documentation new very little about the system and how 
it was used and the mindset of the folks in the field who actually used it. 
In addition the QC folks did also QC the documentation which was a good 
thing. Was their job to understand the project fully :).

My 4cents.
~Marilyn
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] OPEN vs TRANS

[BNeylon]

The actual solution was for me to take the 2 minutes required to comment 
out the TRANS line, add code to open the file, readv the file, comment my 
code, compile and then catalog the program.  Someone who can really type 
would have finished the job in 30 seconds.  :-)
What really hurt was all the time was taken up trying to figure out why 
the flag being set by the TRANS was incorrect.  Now I know.  I have always 
been leery of using a Oconv TRANS in a databasic program.  I was under the 
impression the TRANS had to open the file every time the TRANS was 
executed, now I know better. :-)  Of course, if I had been correct I 
wouldn't have had the problem.  :-(
Learn something new every day.


Bruce M Neylon
Health Care Management Group 




"Keith W. Roberts" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
10/10/2005 11:39 AM
Please respond to u2-users

 
To: , <[EMAIL PROTECTED]>
cc: 
Subject:RE: [U2] OPEN vs TRANS

I understood exactly what you were saying.  The "solution" was for the
case where the acct *wasn't* being exited and therefore @FILENAME,
@RECORD, etc. not flushed.  [Unless, of course, the "cache" you speak of
is something specific to TRANS() rather than the above, but I can't see
why that would be.]

-Keith

Original Message
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert
Sent: Friday, October 07, 2005 2:17 PM
To: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org;
[EMAIL PROTECTED]
Subject: RE: [U2] OPEN vs TRANS

>Why  do  you  believe doing this (Logto followed by LIST
> VOC...) would
>work  ( I don't think it will)?   I think you might have
>misunderstood what  I meant by "exiting the account" - that would
> be 
> using QUIT.   I
>guess I should have been more clear by saying "quitting universe".
> 
> __
> 
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]  On  Behalf
> Of  "Keith W.
>Roberts" <[EMAIL PROTECTED]>
>Sent: Friday, October 07, 2005 1:27 PM
>To: ; <[EMAIL PROTECTED]>
>Subject: RE: [U2] OPEN vs TRANS
> 
>Possible workaround?
>Whenever you LOGTO, do a LIST VOC SAMPLE 1 (HUSHed) to
> change the file
>and record pointers.
>-Keith
>
>Original Message
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
> Glenn Herbert
>Sent: Friday, October 07, 2005 9:35 AM
>To: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org
>Subject: RE: [U2] OPEN vs TRANS
>> You are 100% correct and this is a known issue (to me>
>anyways). The > cache is only flushed when exiting the account or
>when you> return back > to TCL. Unfortunately, there is no
>direct way to call> the internal > transclear() function.
> 
> __
>> > From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On> Behalf Of
>> [EMAIL PROTECTED]
>> Sent: Friday, October 07, 2005 11:22 AM
>> To: u2-users@listserver.u2ug.org
>> Subject: RE: [U2] OPEN vs TRANS
>>
>> Our system has many accounts with, basically, the same
> file names,
>> layouts, etc. We found a problem with using the translate>
>rather than > open/read in programs.
>> If a program logs from account to account and accesses> info
>with a > trans,
>> the trans doesn't always open and read the file in the> new
>account's > file,
>> rather the trans retrieves the info from an earlier account.
>> Am I right is supposing this phenomena is due to the file>
>and record > having the same ID and logging to another account 
>> doesn't flush the > cache?
>> Thanks,
>> Bruce
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Programmers and Documenation.

[Stevenson, Charles]

I prefer to write what essentially becomes the final User Documentation
during the Requirement phase of a project.  It is the spec the users
sign off on and I design and program to that.  

Sure, there were a few mods along the way,  but the approach works very
well.   And yes, there are often other requirements that don't show up
in the user doc (response time, EDI interfaces, etc)  but for the most
part, if you program to the User Doc instead of writing the
documentation after the fact to describe what you programmed, everyone
is happier.

That document very easily evolves into a User Acceptance Test Plan, too.

cds
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Multi-Value Fields and UniBasic

[Jim Cullen]

Figured it out!!

EXTRACT function is the answer!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim Cullen
Sent: Monday, October 10, 2005 10:01 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Multi-Value Fields and UniBasic

I'm using Manage 2000

I've written a routine to pull all records from the 'CM' customer master
file into a text file that's delimited.

My question is what's the best way to separate a multi-valued field,
which in this case is the Addr and Addr2 fields.

I get one big string with both fields in it. Is there perhaps a way in
UniBasic to refer to these fields by name, rather than number?



Thanks



Jim Cullen

IT Manager

Donovan Enterprises

(772)286-6921
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] OPEN vs TRANS

[Keith W. Roberts]

I understood exactly what you were saying.  The "solution" was for the
case where the acct *wasn't* being exited and therefore @FILENAME,
@RECORD, etc. not flushed.  [Unless, of course, the "cache" you speak of
is something specific to TRANS() rather than the above, but I can't see
why that would be.]

-Keith

Original Message
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert
Sent: Friday, October 07, 2005 2:17 PM
To: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org;
[EMAIL PROTECTED]
Subject: RE: [U2] OPEN vs TRANS

>Why  do  you  believe doing this (Logto followed by LIST
> VOC...) would
>work  ( I don't think it will)?   I think you might have
>misunderstood what  I meant by "exiting the account" - that would
> be 
> using QUIT.   I
>guess I should have been more clear by saying "quitting universe".
> 
> __
> 
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]  On  Behalf
> Of  "Keith W.
>Roberts" <[EMAIL PROTECTED]>
>Sent: Friday, October 07, 2005 1:27 PM
>To: ; <[EMAIL PROTECTED]>
>Subject: RE: [U2] OPEN vs TRANS
> 
>Possible workaround?
>Whenever you LOGTO, do a LIST VOC SAMPLE 1 (HUSHed) to
> change the file
>and record pointers.
>-Keith
>
>Original Message
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
> Glenn Herbert
>Sent: Friday, October 07, 2005 9:35 AM
>To: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org
>Subject: RE: [U2] OPEN vs TRANS
>> You are 100% correct and this is a known issue (to me>
>anyways). The > cache is only flushed when exiting the account or
>when you> return back > to TCL. Unfortunately, there is no
>direct way to call> the internal > transclear() function.
> 
> __
>> > From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On> Behalf Of
>> [EMAIL PROTECTED]
>> Sent: Friday, October 07, 2005 11:22 AM
>> To: u2-users@listserver.u2ug.org
>> Subject: RE: [U2] OPEN vs TRANS
>>
>> Our system has many accounts with, basically, the same
> file names,
>> layouts, etc. We found a problem with using the translate>
>rather than > open/read in programs.
>> If a program logs from account to account and accesses> info
>with a > trans,
>> the trans doesn't always open and read the file in the> new
>account's > file,
>> rather the trans retrieves the info from an earlier account.
>> Am I right is supposing this phenomena is due to the file>
>and record > having the same ID and logging to another account   
>> doesn't flush the > cache?
>> Thanks,
>> Bruce
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] OPEN vs TRANS

[Keith W. Roberts]

That was the idea, but I wasn't discussing implememntation, only a
technique that might solve the problem.

-Keith

Original Message
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Allen E. Elwood
Sent: Friday, October 07, 2005 1:20 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] OPEN vs TRANS

> Hey Keith,
> 
> That's a really great idea, but why not just add it to the
> LOGIN paragraph?
> (it's in the VOC on Unidata systems) Then you won't have to
> stub the LOGTO
> command!
> 
> Allen
> www.tortillafc.com
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Keith
> W. Roberts
> Sent: Friday, October 07, 2005 10:27
> To: u2-users@listserver.u2ug.org; [EMAIL PROTECTED]
> Subject: RE: [U2] OPEN vs TRANS
> 
> 
> Possible workaround?
> 
> Whenever you LOGTO, do a LIST VOC SAMPLE 1 (HUSHed) to change the
> file and record pointers. 
> 
> -Keith
> 
> Original Message
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert
> Sent: Friday, October 07, 2005 9:35 AM
> To: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org
> Subject: RE: [U2] OPEN vs TRANS
> 
>>You  are  100% correct and this is a known issue (to me anyways).
>>The cache is only flushed when exiting the account or when you
>>return back to  TCL.   Unfortunately,  there is no direct way to
>>call the internal transclear() function.
>> 
>> 
>> 
> __
>> 
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]  On
>> Behalf Of
>>[EMAIL PROTECTED]
>>Sent: Friday, October 07, 2005 11:22 AM
>>To: u2-users@listserver.u2ug.org
>>Subject: RE: [U2] OPEN vs TRANS
>> 
>>Our system has many accounts with, basically, the same file names,
>>layouts, etc. We found a problem with using the translate rather
>>than open/read in programs.
>>If  a  program  logs  from account to account and accesses info
>>with a trans,
>>the  trans  doesn't always open and read the file in the new
>>account's file,
>>rather the trans retrieves the info from an earlier account.
>>Am I right is supposing this phenomena is due to the file and
>>record having  the  same  ID and logging to another account
>>doesn't flush the cache?
>>Thanks,
>>Bruce
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Unidata TCL - beginner question

[Stevenson, Charles]

Bruce,

There has been several responses, but I don't think you have an answer
yet, do you?

I haven't followed the closely & don't have the original problem,  and
it is unclear to me whether you have multi- or single-valued  date/part
data.

At any rate,  you'll need to make 2 passes on the file,  the first to
sort, and the 2nd to grab only the oldest (or was it youngest?) date for
each part.  If mv, you're going to have to get the BP-EXP keyword in
there.

If UV, I know how I would do it, but I don't think my method would work
in UD, iirc.

On UD can you use SQL SELECT to accomplish the task?

For maintainability's sake, and given how difficult it has been for this
list to supply an answer  (which may indicate that some arbitrary future
maintenance programmer may also have difficulty understanding your
eventual answer), you might want to do the selection in a basic program,
where it would be fairly straightforward.

cds

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Ordway
> Sent: Friday, October 07, 2005 1:11 PM
> To: 'u2-users@listserver.u2ug.org'
> Subject: RE: [U2] Unidata TCL - beginner question
> 
> >SORT filename BY Part BY Date @ID BREAK.ON Part Date DET.SUP<
> BTW, I thought this worked to begin with.
> Then, I started noticing it wasn't really.
> I keep getting dates in the middle of the range for some parts.
> Just so happens I'm working on a huge file, 886817 records.
> I wonder if Unidata SORT's break down if a file is too big or 
> sized incorrectly?
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Programmers and Documenation.

[Marilyn Hilb]

I may not be using the best verbiage.. but I do very much enjoy writing 
documentation. NOT I believe what is called "high-level integrated 
documentation". I think of that as integrating the new features into a very 
large and complex documentation manual on the whole system. "not my job mon".

I do enjoy however witting a 'simple' word document incorporating screen shots 
and what I hope to be realistic usage/samples of the feature in the terms that 
the folks in the field would actually relate to.  

As a single shop here (not having an additional person to do a final QC of the 
project) I use the documentation phase as a final walkthrough and testing of 
the project. After putting the delivery onto a new file set as well, this also 
insures that I got all the pieces onto the delivery :). (yes, no version 
control here.. lets not get into that discussion again please).  In addition I 
send the documentation to some folks in the field so they can approve of the 
project before it is installed. They often come up with good suggestions at 
that time!

Doing the documentation cycle really helps me get an overall view of the 
project and often during this cycle I come up with additional quick bells and 
whistles that really just pull it all together. Amazing what simple/obvious 
things I see during this phase that I didn't see when working deep in the 
detail. I am very happy that even though this is a small shop, I am allowed the 
time to write up documentation. 

Many times I doubt that the folks who use the system give the documentation 
more than a glance.  More than once I get a call asking about the new project.. 
and I answer and 'politely' say.. "it is in the document" and I get back "well, 
I didn't read the documentation".  I grumble under my breath and make my voice 
smile and hang up the phone quickly. 

At my previous position where we had a QC team as well as an official 
documentation team, I was still able to write my documentation for the new 
features only and it was their job to incorporate it into the big manual. 
Worked for me :).  They would also review it (in the cases where it was pure 
custom and did not go into the manual) and proof it for verbiage etc to make it 
a bit more professional sounding. The thing I didn't like about this is the 
folks who did the documentation new very little about the system and how it was 
used and the mindset of the folks in the field who actually used it.  In 
addition the QC folks did also QC the documentation which was a good thing. Was 
their job to understand the project fully :). 

My 4cents.
~Marilyn
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Fw: More U2 programming hints

[gerry-u2ug]

I wasn't asking anything.
I was making a statement regarding the previous post.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson
Sent: Sunday, October 09, 2005 10:32 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Fw: More U2 programming hints


Are you asking if there's a difference between a BASIC SELECT and an EXECUTE
"SELECT"? I don't want to answer the wrong question. But I and others have
the answer if it's this one.

I guess this diverts the question of how to best protect the intregrity of
the entire file when processing the entire file for the possiblilites of
additions or deletions. Neither BASIC SELECT or EXECUTE SELECT is a clear
cut winner. I don't know enough about FILE.LOCK but it sounds likely.

My 1 cent.


- Original Message -
From: "gerry-u2ug" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, October 09, 2005 9:39 PM
Subject: RE: [U2] Fw: More U2 programming hints


> That's ridiculous.
> How is a BASIC select any different from a EXECUTE select in this regard ?
> When you do an EXECUTE "SELECT ..."  a select list is built.
> As you process this list, records could be added that will not appear in
the list.
> Conversely, records that have been selected could be deleted and no longer
exist when the list is processed.
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jeff Marcos
> Sent: Sunday, October 09, 2005 08:26 PM
> To: u2-users@listserver.u2ug.org
> Subject: [U2] Fw: More U2 programming hints
>
>
> I must agree that a BASIC SELECT is quicker but... Don't you run the risk
of
> missing groups (in the read function) in this type of select? If users are
> updating this file they could insert data into a group which you may
already
> passed.
>
>
>
> You would only use this type of select when no one is updating this file.
>
>
>
> Regards,
>
> Jeff Marcos
>
>
>
> -Original Message-
>
> From: [EMAIL PROTECTED]
>
> [mailto:[EMAIL PROTECTED]
>  ] On Behalf Of Mark Johnson
>
> Sent: Thursday, 6 October 2005 10:26 PM
>
> To: u2-users@listserver.u2ug.org
>
> Subject: Re: [U2] Fw: More U2 programming hints
>
>
>
>
>
> I can't see how a BASIC SELECT can be slower than EXECUTE "SELECT". It
>
> doesn't have to go through to get 'xxx items selected' before it processes
>
> the first one. I also don't believe the mechanical difference once it
>
> begins, ie 'find the next group' etc. Wouldn't you think that this at
least
>
> spares the actual hashing as it is navigating through the file
sequentially.
>
>
>
> I would really like to see a great proof program against BASIC SELECT. I
>
> often replace EXECUTE "SELECT" with a BASIC SELECT over the years
*because*
>
> it has always ran faster, regardless of platform. I've had many
>
> opportunities to be proven wrong. I've tested every replacement and have
>
> always reported an improvement.
>
>
>
> Thanks.
>
> MarkJohnson
>
> - Original Message -
>
> From: "Allen E. Elwood" <[EMAIL PROTECTED]>
>
> To: 
>
> Sent: Tuesday, October 04, 2005 5:45 PM
>
> Subject: RE: [U2] Fw: More U2 programming hints
>
>
>
>
>
> > This is the way it was explained to me way back in '88.  The internal
> select
>
> > is slower on the whole file, but immediate in response.  It works the
same
>
> > as LIST.  If I list a file with 2,000,000 records I get immediate
> response.
>
> >
>
> > If I want to process an entire file, then external select is slower on
>
> > response, i.e. I have to wait for 2 million records to be selected
before
>
> > processing begins, but is quicker in processing all records.
>
> >
>
> > The internal is slower due to the system having to stop what it's doing,
>
> > find the next group, break out the individual ID's from that group, and
> then
>
> > return it to the program - over and over again as it makes it's way
> through
>
> > the file.
>
> >
>
> > hth!
>
> >
>
> > Allen
>
> >
>
> > -Original Message-
>
> > From: [EMAIL PROTECTED]
>
> > [mailto:[EMAIL PROTECTED]
>   Behalf Of Stevenson,
>
> > Charles
>
> > Sent: Tuesday, October 04, 2005 14:24
>
> > To: u2-users@listserver.u2ug.org
>
> > Cc: Louis Windsor
>
> > Subject: RE: [U2] Fw: More U2 programming hints
>
> >
>
> >
>
> > This is a bit disconcerting.
>
> > BASIC SELECT should be faster than EXECUTE "SELECT..."
>
> > Maybe the smart people can weigh in on this:
>
> >
>
> > > From: Louis Windsor
>
> > >
>
> > > A few years ago we used the BASIC SELECT FILE as opposed to
>
> > > the EXECUTE "SELECT FILE".
>
> > >
>
> > > We updated UniVerse (don't ask from what version to what
>
> > > version as I don't remember) and overnight ALL our programs
>
> > > ran five or six times longer.
>
> >
>
> > Completely contrary to my experience and counter-intuitive, too.
>
> >
>
> > > We were told (by VMark) that the BASIC SELECT now selected
>
> > > each group but it could be optioned to work the "old" way.
>
> >
>
> > Hmmm, do I vaguel

[U2] Multi-Value Fields and UniBasic

[Jim Cullen]

I'm using Manage 2000

I've written a routine to pull all records from the 'CM' customer master
file into a text file that's delimited.

My question is what's the best way to separate a multi-valued field,
which in this case is the Addr and Addr2 fields.

I get one big string with both fields in it. Is there perhaps a way in
UniBasic to refer to these fields by name, rather than number?



Thanks



Jim Cullen

IT Manager

Donovan Enterprises

(772)286-6921
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] Visual Schema Generator 'unable to open dictionary of sysobjects'

[Simon Lewington]

Wendy

To set up a new UDT account for SQL and ODBC we...

1) Log off and back on to ensure that Unidata clears it SQL cache.

2) Delete all the VOC and file system files for all the SQL/ODBC files
except __V__VIEW (which is created by newacct).  Our current list is:

privilege
SQLColumns SQLSpecialColumns SQLStatistics SQLTables
sysalternates syscolumns sysindexes sysobjects sysprotects sysusers
__SCHEMA__MAP __SCHEMA__PROC

If you've already got stuff in the SQL files then you'll need to work out
what to do about that.

3) Run 'sql' (and simply exit) to create the sql files.

4) Call the API program SCHEMA_MIGRATE(ERR,ERRTXT) from a basic program to
create the ODBC files.

Simon

"Wendy Smoak" ...
> I'm trying (first time) to use VSG on an account, and all it will do is
> complain:  'Unable to open dictionary of sysobjects'.
>
> All I can find online is a post on the u2ug forums from a person who had
the
> same problem a while ago.  I also consulted our VAR's knowledge base, and
> found an article that said to make sure the various sys* files
(sysobjects,
> syscolumns, etc.,) do NOT exist in the account, because VSG will create
> them.  Is that correct?
>
> We did have 'empty' VOC pointers hanging around from somewhere, but none
of
> the files were there.  I deleted the VOC pointers to sysobjects, etc., but
> it didn't help.  The This is on UniData 6.0 on HP-UX.
>
> Any ideas?
>
> Thanks,
> Wendy Smoak
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Printer problems on UV PE under Windows XP

[Brian Leach]

Eric,

Can we start from the top:

1. Is this a local printer or a share e.g. \\machine\printer ?
2. If remote, is it installed under Windows? If so, does your UniVerse user
have privilege to access it?
3. Does the printer show up if you do a SPOOL -LIST ? Is there an error code
reported when you do?
4. If local, can you set the printer to FILE (printer->Properties->Ports)
and see any output?
5. Are the printer drivers locally installed?
6. If remote, try setting up the printer as a local printer (on
\\machine\share) an try using the generic/text only driver.

Brian

> 
> Folks,
> 
> I've been struggling to set up a printer. After much tweaking 
> and twiddling, I finally can actually see the printer in 
> U2ADMIN, but still can't seem to get anything to print to it.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] OPEN vs TRANS + Vector

[Stuart . Boydell]

   Wow, thanks! and caveat heeded.
   Vectorally (and RTFM) challenged,
   Stuart

   -Original Message-
   From:  "Stevenson, Charles"

 Vectoring (is 'vector' a verb?) is built into TRANS already.
 No need to abandon in favour of OCONVS T-correlative.
 You can specify a dynamic array of IDs for the target file to read.
 > I have used the Translate code with OCONVS() function when it
 > is stylistically in keeping with the use of vector functions
 > around it and only because there isn't a vector version of
 >  TRANS(),  but  personally  I  wouldn't  use  it  outside of that
 situation.
 >
 > custProductIDs = splice(reuse(custId),'*',productIds)
 instead of / as well as this:
 > prices = oconvs(custProductIDs,'TCUST.PRODUCT;X;;99')
 this works fine (even better I think):
 prices = TRANS( 'CUST.PRODUCT', custProductIDs, 99, 'X' )
 But a caution:
 If CUST.PRODUCT <99> is multivalued &/or sub-valued:
 *  T-correlative  converts  all  delimiters  to  spaces when OCONVS
 returns.
 (consistent with PICK.)
 * TRANS will lower the returned delimiters.
 (almost consistent with PI.)
 - if called from Retrieve, the delimiters are lowered enough to
 keep the association with the dict equivalent of custProductIDs
 which might be multi-SUB-valued or even have TMs or lower.
 - if called from Basic, not that smart, just lowered once,
 so you might lose the association with custProductIDs.
 The above for UV. Mileage for UD may vary.
 cds
 ---
 u2-users mailing list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/

   **

   This email message and any files transmitted with it are confidential

   and intended solely for the use of addressed recipient(s). If you have

   received  this  email  in  error please notify the Spotless IS Support
   Centre (+61 3 9269 7555) immediately, who will advise further action.

   This footnote also confirms that this email message has been scanned

   for the presence of computer related viruses.

   **
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/