Re: [U2] Using DICT items in basic program
On 16/05/11 07:19, Dan McGrath wrote: If you are using UniData you can create an I-type dictionary. For the location (attribute 2 in the dictionary) put either EXTRACT(@RECORD,2,2,0) or, alternatively, if you already have a D-Type dictionary for the 2nd field (let us call it ADDRESS for arguments sake), you could put EXTRACT(ADDRESS,1,2,0) Now, if we called the above dictionary item 'CITY', you can get your required listing (sorted by CITY, ascending) by: LIST CLIENT CITY BY CITY If you are using UniVerse, this should be fairly similar. In UV it should be even simpler ... :-) Assuming field 2 is called ADDRESS, you can create an i-descriptor with ADDRESS1,2 in field 2. Regards, Dan Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Using DICT items in basic program
Hi, Can you tell me how can we crate a dict item to sort a specific multivalue. For eg a file name is CLIENT. And I want to list the CLIENT keys with 2nd multivalue of 2st field. i.e CLIENT Vaishali 1 2 Pune char(253)mumbai and when I list the result should appear like : Vaishali mumbai. Your help will be appriciated. Thanks, ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Using DICT items in basic program
If you are using UniData you can create an I-type dictionary. For the location (attribute 2 in the dictionary) put either EXTRACT(@RECORD,2,2,0) or, alternatively, if you already have a D-Type dictionary for the 2nd field (let us call it ADDRESS for arguments sake), you could put EXTRACT(ADDRESS,1,2,0) Now, if we called the above dictionary item 'CITY', you can get your required listing (sorted by CITY, ascending) by: LIST CLIENT CITY BY CITY If you are using UniVerse, this should be fairly similar. Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Vaishali Patil Sent: Monday, 16 May 2011 4:04 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Using DICT items in basic program Hi, Can you tell me how can we crate a dict item to sort a specific multivalue. For eg a file name is CLIENT. And I want to list the CLIENT keys with 2nd multivalue of 2st field. i.e CLIENT Vaishali 1 2 Pune char(253)mumbai and when I list the result should appear like : Vaishali mumbai. Your help will be appriciated. Thanks, ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ### The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files with the permission of IMB. ### ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Using DICT items in basic program
The more you build into it the more overhead you create. Not all businesses would need the object you are talking about, as well as other objects you may think of. The beauty of the current system is that you are not encumbered by unnecessary overhead and how somebody else thinks a process should work. It's bad enough you have to deal with that on PC apps. If you have a need for this then build it, but don't encumber the rest of us with something we may not need. Jerry - Original Message - From: David Jordan [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Monday, September 04, 2006 4:02 PM Subject: RE: [U2] Using DICT items in basic program This concept is something that the PICK world needs to look at. Intersystems Cache deals with Data Objects which is a combination of data and business logic. That data object is written once and used everywhere from a query, from in a program, from a web services, from .Net, java, etc. This appears to work quite efficiently in Cache although I have not had the chance to play with it. I am sure that I am not the only developer out there who has explored this concept in PICK and thought it would be highly effective if it could be done efficiently. Consider Total Price = Qty * Unit Price. This would be duplicated in an application from an Enqlish statement to a data entry program, to report programs to a web client, etc. Every one duplicating the reading of Qty and Unit price from the database and writing the calculation for each application. Consider now we need to add tax or a customer discount, that logic would need to be duplicated through every program, wouldn't it be nice if we just had to change it in one place. Maybe this is a future development direction for the IBM folks to consider. Regards David Jordan --- 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] Using DICT items in basic program
Hi Jerry The more you build into it the more overhead you create. Not all businesses would need the object you are talking about, as well as other objects you may think of. The beauty of the current system is that you are not encumbered by unnecessary overhead and how somebody else thinks a process should work. It's bad enough you have to deal with that on PC apps. If you have a need for this then build it, but don't encumber the rest of us with something we may not need. Jerry I would see this as an enabler, an alternative method and not a forced encumberment. If you don't want to use it, I don't see that it would really impact on performance on current methods, if it is done right. The elements are already in place, it is a matter of making the ITYPE concept more interactive, efficient and effective with BASIC, uniObjects, SQL, xml. This might entail a new command such as READI which reads virtual fields (itypes) into the attributes automatically, or stores the calculation in a variable similar to an equate statement process. Some of this can be built over the top of the current process, but there are limitations and inefficiencies which would be overcome if built we build some of these processes into the base. At the moment I am just putting a thought out their to see how we can develop U2 further and make it more inviting to a new audience of users, of course without undermining the current base. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
Thank you Brian for your observations. I'm of the Jurrasic Pick era with 95% of my world being mv and the other 5% being MS Access. I am enjoying the GUI development environment of Accuterm and may convert upcoming MS clients to that GUI front end on top of D3 as the client doesn't care that much about back end databases when it has a nice front end. I've inherited many, many systems (45 in the last 10 years alone) with their incredibly diverse and over-written methods for many, many tasks. Certainly I've not seen everything but I've seen a ton of programming of which I can extract the best methods to continuously add to my own personal library of what's effecient. I can also ignore the less intelligent ineffeciencies. My download utility's purpose is for the one-time project. It's pretty much a TCL only command issued typically by the only cook in the kitchen, me. I've written many portable subs that I install at all of my clients for their recurring needs. While there could be some extension of unidata/universe that allows direct writing to a PC folder, most implementations don't have it that easy. The native ones don't have it at all. Thus I develop my subroutines and tweak them per mv flavour on which they're installed. Thus whether it's UD/UV, D3, Mvbase, Microdata or native systems, DOWNLOAD works the same as well as most of my subroutines. If I were to add DOWNLOAD to a proc or a program, my experience would prevent me from performing 5 million executes and approach the solution with a more effecient method. I have subs that easily make CSV's or simple HTML's and have automated many import/export facilities including unix-ftp, MS-ftp, VB scripts and other contemporary attachments. Thus, if my clients were to convert to other version of MV, only my subs need be changed and not the local changes in dozens if not hundreds of programs. One sub that answered the original post is called GET.DICT(FILE, ID, VAL) which has the embedded English sentence mentioned earlier. I use it in DOWNLOAD as well as I've put it in regular CUSTOMER maintenance or other single item programs to get the results of a complex expression instead of writing the same code again. If the logic is complex or has the possibility of being changed, business-wise, changing the dict reference causes its use elsewhere to be changed as well. One thing I miss in D3 that I enjoy in UD/UV is the more advanced called subs from dict items. D3's versions can only pass (return) one parameter in the parameter string. It has access (ACCESS()) to the item-id, file and record but only once you're in the sub. It also gets a little funky when returning multi-valued values. The joy in the UD/UV called subs is that the sub being called doesn't care if it's called from English or a basic program. Thus, the intelligence can be shared whereby in D3 is has to be replicated or managed in a more klugy way. Score one for U2. My 3 cents. Mark Johnson - Original Message - From: Brian Leach [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, August 03, 2006 9:24 AM Subject: RE: [U2] Using DICT items in basic program Tim/Mark You both make good points. Mark was responding to a specific requirement (how to get a single field for a single record) with one working and largely cross platform solution. Obviously getting a tranch of data requires a different solution. I don't think Mark was seriously suggesting that a million executes is a way to go. Personally I would now look towards XML as that seems to be the best current option for integrating the enquiry and development languages - finally something native to close that gap in the PICK model - though in the past I have used everything from REFORMAT (slow but predicatable) to creating compound I Descriptors of the form: CONVERT(@FM:@VM:@SVM,CHAR(1):CHAR(2):CHAR(3),field1:@FM:field2:@FM ...) etc and doing a SELECT .. SAVING that descriptor. Each ReadNext then gets an entire row - just CONVERT() the delimiters back again - and the result is extremely fast. Doesn't work well with WHEN clauses though - but then few things really do :( Tim's point about DOWNLOAD does have some merit. But Mark is an old pro (sorry, forgive the 'old' bit ! ) and I'm sure he writes his utilities in a way that other developers can work out what they do grin. Calling a utility without looking to see how it works first - well that's just lazy. And it's not just MV that will screw up in those cases! You wouldn't expect to call a SQL Server or Oracle stored procedure without some DBA's approval, would you? Brian --- 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] Using DICT items in basic program
This concept is something that the PICK world needs to look at. Intersystems Cache deals with Data Objects which is a combination of data and business logic. That data object is written once and used everywhere from a query, from in a program, from a web services, from .Net, java, etc. This appears to work quite efficiently in Cache although I have not had the chance to play with it. I am sure that I am not the only developer out there who has explored this concept in PICK and thought it would be highly effective if it could be done efficiently. Consider Total Price = Qty * Unit Price. This would be duplicated in an application from an Enqlish statement to a data entry program, to report programs to a web client, etc. Every one duplicating the reading of Qty and Unit price from the database and writing the calculation for each application. Consider now we need to add tax or a customer discount, that logic would need to be duplicated through every program, wouldn't it be nice if we just had to change it in one place. Maybe this is a future development direction for the IBM folks to consider. Regards David Jordan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 09/03/2006 01:11:43 AM: Anyone can create an example of extremes to invalidate any suggestion. I didn't really see one million records as being extreme. That's really not a very big file in today's world. Since many people here are working on large systems, I just wanted to give them a heads-up before they implement logic that drags down their systems. You never said this was for only small sets of records, so I felt people needed to be aware of the limitations. Many people who come here are new to the MV world, and we need to look out for them. If I were intending to process 5 million records as you would suggest, I would write a simple program to create the csv's. I create many of these as programs for their recurring use. I use download for the one-shot simple projects. The problem is that somebody could inherit the system years later, see something called DOWNLOAD, and assume it will work for their needs. Unless there are built-in warnings that say they should only process VERY small data sets with this logic, they're going to get bitten. And we all know that one-time programs often make into production. Who here has never had that happen? :-) Besides, so what if it did 5 million executes. These systems can handle it. I know the common thinking these days is that the hardware can handle anything that programmers throw at it, and that programmer time is more expensive than hardware. Therefore, programmers should just put something together that works and let the system handle it. If not, you can always buy more hardware. When programmers think that way, their employers end up bringing in people like me to make it right - not that I'm complaining. :-) With one line of BASIC code you can consume an entire CPU. If your system has four CPUs, that's 25% of the entire system's capacity! Run that program in four different sessions and you've bogged down the entire system. Yes, hardware has come down in price over the years, but nobody's giving away CPUs yet. Also, the fact is that faster, more powerful systems very often exploit inefficient coding practices, and can create some very nasty bottlenecks. Time or processor consumption wasn't an issue in the original request Again, just warning people. It's my belief that system efficiency should always be a key consideration in developing software. I acknowledge that you shouldn't agonize over every CPU cycle, but it doesn't take that much longer to consider how coding and implementation practices will impact the entire system. Unfortunately, performance is generally seen as a problem for the SAs and DBAs to solve. In the VAST majority of cases that I've come across, the best performance improvements come from cleaning up the application code. Please understand that I'm not picking on anyone here. Just trying to help people understand the consequences of the decisions they make while developing systems. When systems perform sluggishly, there's a tendency to blame that oddball Uni-whatchamacallit database. The more we all do to keep the application humming along, the better off we'll all be. And if anybody out there isn't sure how to make that happen, there are plenty of us out here that are willing to help out. [Wipes brow and steps down from soapbox] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Using DICT items in basic program
Timothy Snyder stated: ...system efficiency should always be a key consideration in developing software. BIG AMEN. This statement should be printed in BIG BOLD letters and framed over every developer's desk. System efficiency is the responsibility of every developer, not of the machine. Forcing a solution that works at the expense of performance and/or readability is no solution at all. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Using DICT items in basic program
Tim/Mark You both make good points. Mark was responding to a specific requirement (how to get a single field for a single record) with one working and largely cross platform solution. Obviously getting a tranch of data requires a different solution. I don't think Mark was seriously suggesting that a million executes is a way to go. Personally I would now look towards XML as that seems to be the best current option for integrating the enquiry and development languages - finally something native to close that gap in the PICK model - though in the past I have used everything from REFORMAT (slow but predicatable) to creating compound I Descriptors of the form: CONVERT(@FM:@VM:@SVM,CHAR(1):CHAR(2):CHAR(3),field1:@FM:field2:@FM ...) etc and doing a SELECT .. SAVING that descriptor. Each ReadNext then gets an entire row - just CONVERT() the delimiters back again - and the result is extremely fast. Doesn't work well with WHEN clauses though - but then few things really do :( Tim's point about DOWNLOAD does have some merit. But Mark is an old pro (sorry, forgive the 'old' bit ! ) and I'm sure he writes his utilities in a way that other developers can work out what they do grin. Calling a utility without looking to see how it works first - well that's just lazy. And it's not just MV that will screw up in those cases! You wouldn't expect to call a SQL Server or Oracle stored procedure without some DBA's approval, would you? Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
I am fully aware of the possibility of 5 executes for 1 million records
totalling 5 million executes.
Anyone can create an example of extremes to invalidate any suggestion. My
example was to acquire the results of a dict item within basic, one of those
missing elements that my sub can handle.
If I were intending to process 5 million records as you would suggest, I
would write a simple program to create the csv's. I create many of these as
programs for their recurring use. I use download for the one-shot simple
projects.
Besides, so what if it did 5 million executes. These systems can handle it.
Time or processor consumption wasn't an issue in the original request
My 1 cent
Mark Johnson
- Original Message -
From: Timothy Snyder [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Thursday, August 31, 2006 9:57 PM
Subject: Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/31/2006 07:03:29 PM:
The magic is to take the TCL statement, derive the filename (CUSTOMER)
and
using READNEXT, acquire each of the item id's from the SSELECT
statement.
Then I generate very tiny English statements of the form:
EXECUTE LIST FILE ID NAME ID-SUPP COL-HDR-SUPP {any other necessary
suppressors} CAPTURING X
If I'm reading this correctly, you're performing multiple executes for
each record in the file. In the example you provided, you would be
performing one execute each for NAME, CSZ, PHONE, CONTACT, and
AGED.BALANCE. If you're processing a million records, that means you'll
be performing FIVE-MILLION executes!!!
Maybe I've misunderstood what you're doing. But if not, I don't recommend
this approach. The overhead of performing that many executes is
staggering. I had a customer that had a process that was running in eight
hours, and they desperately wanted to get it down to four hours. It was
consuming an entire CPU and imposing significant I/O wait times that
impacted system-wide performance. I found where the program was spending
most of its time and CPU cycles - it was in a routine that was performing
executes to locate a value within an index and read through that. I
changed it to eliminate the executes and use intrinsic basic functions
instead - nothing else was changed. It went down to twenty minutes - much
better than they had hoped for. CPU and disk consumption became
insignificant. Executes are a wonderful thing, but they are very
expensive operations when performed many times. By adding the capturing
clause, you're adding even more overhead.
---
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] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/31/2006 05:42:44 AM: CUT HERE --- SUBROUTINE stdValue( FileName, FieldName, Id, Record, Value ) Open DICT, FileName To DFL Else RETURN End Read DictRec From DFL, FieldName Else RETURN End @Id = Id @Record = Record @Dict = FileName Does this last statement work? According to the UniBasic Command Ref, @DIST should be set to the file handle DFL from an open statement, not a file name. The example in the docs goes like this: OPEN 'DICT','ORDERS' TO @DICT ELSE STOP 'NO DICTIONARY FOR ORDERS FILE' END If yours works, it must be one of those many undocumented features of Unidata. RETURN End cut __ This email has been scanned by the MessageLabs Email Security System. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 11/29/2003 ACE Software, LLC --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Using DICT items in basic program
In UniData it does... From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Fri 9/1/2006 5:04 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Using DICT items in basic program [EMAIL PROTECTED] wrote on 08/31/2006 05:42:44 AM: CUT HERE --- SUBROUTINE stdValue( FileName, FieldName, Id, Record, Value ) Open DICT, FileName To DFL Else RETURN End Read DictRec From DFL, FieldName Else RETURN End @Id = Id @Record = Record @Dict = FileName Does this last statement work? According to the UniBasic Command Ref, @DIST should be set to the file handle DFL from an open statement, not a file name. The example in the docs goes like this: OPEN 'DICT','ORDERS' TO @DICT ELSE STOP 'NO DICTIONARY FOR ORDERS FILE' END If yours works, it must be one of those many undocumented features of Unidata. RETURN End cut __ This email has been scanned by the MessageLabs Email Security System. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 11/29/2003 ACE Software, LLC --- 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] Using DICT items in basic program
Bob Here's one I had lying around. Hack it as you will :) Regards, Brian CUT HERE --- SUBROUTINE stdValue( FileName, FieldName, Id, Record, Value ) *-- * Name: stdValue * Description : Get a field value from the dictionary * Author : Brian Leach * Project : STD * Module : GENERAL *-- Value = Open DICT, FileName To DFL Else RETURN End Read DictRec From DFL, FieldName Else RETURN End @Id = Id @Record = Record @Dict = FileName First = UpCase(TrimF(DictRec))[1,1] Begin Case Case First = D Value = (Id:@fm:Record)DictRec2+1 Conv = DictRec3 Case First = I Value = IType(DictRec) Conv = DictRec3 Case First = A Or First = S Value = (Id:@fm:Record)DictRec2+1 If DictRec8 Then Value = OConv(Value, DictRec8) End Conv = DictRec7 Case 1 Return End Case If Conv Then Value = OConvS(Value,Conv) End RETURN End cut --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Using DICT items in basic program
Brian, Here is a helpful hint, make the first value of your subroutine the Return Value. This way it can also be used from an I-Desc. Thanks, David A. Green DAG Consulting -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Thursday, August 31, 2006 2:43 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Using DICT items in basic program Bob Here's one I had lying around. Hack it as you will :) Regards, Brian CUT HERE --- SUBROUTINE stdValue( FileName, FieldName, Id, Record, Value ) *-- * Name: stdValue * Description : Get a field value from the dictionary * Author : Brian Leach * Project : STD * Module : GENERAL *-- Value = Open DICT, FileName To DFL Else RETURN End Read DictRec From DFL, FieldName Else RETURN End @Id = Id @Record = Record @Dict = FileName First = UpCase(TrimF(DictRec))[1,1] Begin Case Case First = D Value = (Id:@fm:Record)DictRec2+1 Conv = DictRec3 Case First = I Value = IType(DictRec) Conv = DictRec3 Case First = A Or First = S Value = (Id:@fm:Record)DictRec2+1 If DictRec8 Then Value = OConv(Value, DictRec8) End Conv = DictRec7 Case 1 Return End Case If Conv Then Value = OConvS(Value,Conv) End RETURN End cut --- 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] Using DICT items in basic program
I have used the calculate stmt in a product that I developed for an
interface between Manage-2000 and Demand Solutions (It's now a part of M2K's
product line). I set up a screen so people could enter dict names that
would be additional sorts and additional data to be used in the formation
and content of the data to be passed.
Works like a charm. You definitely want to use calculate as it will work
with *ANY* dict item. TRANS, basic subr's; the whole enchilada!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Timothy Snyder
Sent: Wednesday, August 30, 2006 19:23
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/30/2006 08:59:24 PM:
It sounds to like what you want is the TRANS() BASIC function.
This works in UniVerse - Don't know about UniData.
In UniData you can use CALCULATE() or the curly braces {} like you're used
to. The documentation for both formats is in the manual under CALCULATE.
---
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] Using DICT items in basic program
I've created a utility that allows me to process an English statement
(output columns only, the select and sort are done prior) to produce a
free-form CSV.
SSELECT CUSTOMER WITH STATE = NJ AND WITH AGED.BALANCE GT 100
DOWNLOAD CUSTOMER NAME CSZ PHONE CONTACT AGED.BALANCE (C:\FOLDER\ABC.CSV
Thus, my download utility will parse the sentence and derive the values for
the output dict items.
The magic is to take the TCL statement, derive the filename (CUSTOMER) and
using READNEXT, acquire each of the item id's from the SSELECT statement.
Then I generate very tiny English statements of the form:
EXECUTE LIST FILE ID NAME ID-SUPP COL-HDR-SUPP {any other necessary
suppressors} CAPTURING X
and viola, the variable X contains the single row, single column value of
that customer's NAME.
So your request is a variant of just processing a specific file with one or
more ID's for one field. Using English allows the magic of the correlatives
to dothe work so you don't have to re-write anything.
I've implemented this in Ud/Uv, D3, Mvbase. It's too cumbersome on Microdata
and mvbase has a quirk where the CAPTURING doesn't inhibit the screen output
so it gets a little busy.
My 2 cents.
Mark Johnson
- Original Message -
From: Bob Woodward [EMAIL PROTECTED]
To: U2-Users List u2-users@listserver.u2ug.org
Sent: Wednesday, August 30, 2006 6:21 PM
Subject: [U2] Using DICT items in basic program
Hi folks,
I'm trying to set up a general use utility and what I'd like to do is to
be able to call this utility, passing it an open file handle, a couple
other parameters plus one that could be used to specify a dict entry
name, not a field number. The catch is I'd like to use the dict entry
regardless of what type of definition it is. Obviously there would be
some limits but the general definition is that the dict item ultimately
points to a piece of data. An example would be I would want to use a
data position field like CUST.NUM in the INVOICE file. I'd also want to
be able to use something like CUST.NAME in the INVOICE file which would
be a pointer to the CUSTOMER file's NAME field. The utility would use
READ or maybe XLATE to obtain the desired information. I looked at
ITYPE() but I'm not sure that's going to get me what I'm looking for.
In AREV it was simply using the {} brackets.
TIA
BobW
---
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] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/31/2006 07:03:29 PM:
The magic is to take the TCL statement, derive the filename (CUSTOMER)
and
using READNEXT, acquire each of the item id's from the SSELECT
statement.
Then I generate very tiny English statements of the form:
EXECUTE LIST FILE ID NAME ID-SUPP COL-HDR-SUPP {any other necessary
suppressors} CAPTURING X
If I'm reading this correctly, you're performing multiple executes for
each record in the file. In the example you provided, you would be
performing one execute each for NAME, CSZ, PHONE, CONTACT, and
AGED.BALANCE. If you're processing a million records, that means you'll
be performing FIVE-MILLION executes!!!
Maybe I've misunderstood what you're doing. But if not, I don't recommend
this approach. The overhead of performing that many executes is
staggering. I had a customer that had a process that was running in eight
hours, and they desperately wanted to get it down to four hours. It was
consuming an entire CPU and imposing significant I/O wait times that
impacted system-wide performance. I found where the program was spending
most of its time and CPU cycles - it was in a routine that was performing
executes to locate a value within an index and read through that. I
changed it to eliminate the executes and use intrinsic basic functions
instead - nothing else was changed. It went down to twenty minutes - much
better than they had hoped for. CPU and disk consumption became
insignificant. Executes are a wonderful thing, but they are very
expensive operations when performed many times. By adding the capturing
clause, you're adding even more overhead.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
* This is for UniVerse, has been used in versions 7.3 and later. FUNCTION ReadHashedFile(HashedFile,KeyValue,FieldToReturn) $COPYRIGHT Copyright (c) 2002-2006, Ray Wurlod. All rights reserved. May be freely used with this copyright notice intact. * Hashed file may be given as a VOC name or pathname. If both exist, the VOC name takes precedence. * The record whose key value is supplied is read, and the field requested is returned. * The field may be requested by name or by number. If there is a field whose name is a number, * irrespective of the actual storage location, that takes precedence. $INCLUDE UNIVERSE.INCLUDE FILEINFO.H $INCLUDE UNIVERSE.INCLUDE INFO_KEYS.H * Determine whether HashedFile entry occurs in VOC file. CALL !VOC.PATHNAME(IK$DATA, (HashedFile), Pathname, TempVocNeeded) Ans = @NULL HashedFileName = HashedFile If TempVocNeeded Then DirPath = FilePath = CALL !GET.PATHNAME(HashedFile, DirPath, FilePath, Status) CALL !MAKE.PATHNAME(DirPath, D_:FilePath, DictPath, Status) VocName = FilePath : .$$TMP$$. : @USERNO VocEntry = F : @FM : HashedFile : @FM : DictPath Open VOC To Voc.fvar Then RecordLockU Voc.fvar,VocName Write VocEntry To Voc.fvar, VocName Then HashedFileName = VocName End End End * Open hashed file and its dictionary (to retrieve field name definition) Open HashedFileName To File.fvar Else File.fvar = 0 Open DICT,HashedFileName To File.dfvar Else File.dfvar = 0 If FileInfo(File.fvar, FINFO$IS.FILEVAR) And FileInfo(File.dfvar, FINFO$IS.FILEVAR) Then Read DictEntry From File.dfvar, FieldToReturn Then * Dict entry was found. Ans = ; * in case of PH or X entry (A and S not handled either) Begin Case Case FieldToReturn = -1 ; * special override Read Ans From File.fvar,KeyValue Else Ans = Case Left(DictEntry,1) = D ReadV Ans From File.fvar,KeyValue,DictEntry2 Else Ans = Case Left(DictEntry,1) = I Ans = Read @RECORD From File.fvar,KeyValue Then @ID = KeyValue Ans = Fmt(Oconv(Itype(DictEntry),DictEntry3),DictEntry5) End End Case End Else * Dict entry not found Ans = If Num(FieldToReturn) Then If FieldToReturn 0 Then Read Ans From File.fvar,KeyValue Else Ans = Else ReadV Ans From File.fvar,KeyValue,FieldToReturn Else Ans = End End End If TempVocNeeded Then Delete Voc.fvar, VocName Close Voc.fvar End RETURN(Ans) END --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
Trouble with using OCONV is if the correlative contains a field number it
doesn't know what to do with it.
We have used REFORMAT to get data using dictionaries. Made a file per user,
and put the output into the file then read it back.
HTH, Kate
- Original Message -
From: Timothy Snyder [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Friday, September 01, 2006 1:57 PM
Subject: Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/31/2006 07:03:29 PM:
The magic is to take the TCL statement, derive the filename (CUSTOMER)
and
using READNEXT, acquire each of the item id's from the SSELECT
statement.
Then I generate very tiny English statements of the form:
EXECUTE LIST FILE ID NAME ID-SUPP COL-HDR-SUPP {any other necessary
suppressors} CAPTURING X
If I'm reading this correctly, you're performing multiple executes for
each record in the file. In the example you provided, you would be
performing one execute each for NAME, CSZ, PHONE, CONTACT, and
AGED.BALANCE. If you're processing a million records, that means you'll
be performing FIVE-MILLION executes!!!
Maybe I've misunderstood what you're doing. But if not, I don't recommend
this approach. The overhead of performing that many executes is
staggering. I had a customer that had a process that was running in eight
hours, and they desperately wanted to get it down to four hours. It was
consuming an entire CPU and imposing significant I/O wait times that
impacted system-wide performance. I found where the program was spending
most of its time and CPU cycles - it was in a routine that was performing
executes to locate a value within an index and read through that. I
changed it to eliminate the executes and use intrinsic basic functions
instead - nothing else was changed. It went down to twenty minutes - much
better than they had hoped for. CPU and disk consumption became
insignificant. Executes are a wonderful thing, but they are very
expensive operations when performed many times. By adding the capturing
clause, you're adding even more overhead.
---
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] Using DICT items in basic program
Assuming you're dictionary items are D-types, just read the dict item
then use field 2 as a field number to extract the data from your record.
Use field 3 with OCONV and use field 5 with FMT.
If you want to use I-types, simply set @RECORD to the contents of your
data record, and @ID to the record id, and then use the ITYPE function.
eg.
READ DATA.REC FROM FILE.VAR,DATA.ID
ELSE STOP
READ DICT.REC FROM DICT.VAR,DICT.ID
ELSE STOP
* D-type example
FIELD.NO= DICT.REC2
CONV = DICT.REC3
FORMAT = DICT.REC5
CRT FMT(OCONV(DATA.RECFIELD.NO,CONV),FORMAT)
* I-type example
READ ITYPE.REC FROM DICT.VAR,ITYPE.ID
ELSE STOP
CONV = ITYPE.REC3
FORMAT = ITYPE.REC5
@RECORD = DATA.REC
@ID = DATA.ID
THE.DATA = ITYPE(ITYPE.REC)
CRT FMT(OCONV(THE.DATA,CONV),FORMAT)
AdrianW
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Woodward
Sent: Thursday, 31 August 2006 6:21 AM
To: U2-Users List
Subject: [U2] Using DICT items in basic program
Hi folks,
I'm trying to set up a general use utility and what I'd like to do is to
be able to call this utility, passing it an open file handle, a couple
other parameters plus one that could be used to specify a dict entry
name, not a field number. The catch is I'd like to use the dict entry
regardless of what type of definition it is. Obviously there would be
some limits but the general definition is that the dict item ultimately
points to a piece of data. An example would be I would want to use a
data position field like CUST.NUM in the INVOICE file. I'd also want to
be able to use something like CUST.NAME in the INVOICE file which would
be a pointer to the CUSTOMER file's NAME field. The utility would use
READ or maybe XLATE to obtain the desired information. I looked at
ITYPE() but I'm not sure that's going to get me what I'm looking for.
In AREV it was simply using the {} brackets.
TIA
BobW
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
DISCLAIMER:
Disclaimer. This e-mail is private and confidential. If you are not the
intended recipient, please advise us by return e-mail immediately, and delete
the e-mail and any attachments without using or disclosing the contents in any
way. The views expressed in this e-mail are those of the author, and do not
represent those of this company unless this is clearly indicated. You should
scan this e-mail and any attachments for viruses. This company accepts no
liability for any direct or indirect damage or loss resulting from the use of
any attachments to this e-mail.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
Hi Bob,
It sounds to like what you want is the TRANS() BASIC function.
This works in UniVerse - Don't know about UniData.
TRANS (filename, record.ID, field#, control.code)
field# can also be a Dict name.
Regards,
Adrian
On 31/8/06 8:21 AM, Bob Woodward [EMAIL PROTECTED] wrote:
Hi folks,
I'm trying to set up a general use utility and what I'd like to do is to
be able to call this utility, passing it an open file handle, a couple
other parameters plus one that could be used to specify a dict entry
name, not a field number. The catch is I'd like to use the dict entry
regardless of what type of definition it is. Obviously there would be
some limits but the general definition is that the dict item ultimately
points to a piece of data. An example would be I would want to use a
data position field like CUST.NUM in the INVOICE file. I'd also want to
be able to use something like CUST.NAME in the INVOICE file which would
be a pointer to the CUSTOMER file's NAME field. The utility would use
READ or maybe XLATE to obtain the desired information. I looked at
ITYPE() but I'm not sure that's going to get me what I'm looking for.
In AREV it was simply using the {} brackets.
TIA
BobW
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
--
Adrian Overs
Phone : +61 (0)2 9484-7160
Mobile: +61 (0)411 358 354
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 08/30/2006 08:59:24 PM:
It sounds to like what you want is the TRANS() BASIC function.
This works in UniVerse - Don't know about UniData.
In UniData you can use CALCULATE() or the curly braces {} like you're used
to. The documentation for both formats is in the manual under CALCULATE.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
