DEFINE TEMP-TABLE tt_pay_terms NO-UNDO
FIELD pt_terms_code LIKE payment_terms.terms_code
FIELD pt_description LIKE payment_terms.description.
DEFINE VARIABLE htt AS HANDLE NO-UNDO.
htt = TEMP-TABLE tt_pay_terms:HANDLE.
FOR EACH platte.payment_terms
WHERE (
active = true
AND system_id = "000000"
)
NO-LOCK:
CREATE tt_pay_terms.
ASSIGN
pt_terms_code = payment_terms.terms_code.
pt_description = payment_terms.description.
END.
htt:WRITE-JSON("FILE", "/dev/stdout", FALSE).
I have written this query and it returns data like this
[pt_terms_code] => 0.4%!N(MISSING)ET46
[pt_description] => 0.4%! (MISSING)DAYS NET 46
While I believe (from using a SQL query) that the data should be
0.4%45NET46
0.4% 45 DAYS NET 46
I'm making an assumption that the % is probably some special character (as I've run into similar issues in the past). I've tried pulling all the data from the table, and I get the same result, (ie, not creating a temp table and populating it with all the only the two fields I want).
Any suggestions around this issue?
I'm still very new to 4gl, so the above query might be terribly wrong. All comments and criticisms are welcome.
I suspect that if you try this:
FOR EACH platte.payment_terms NO-LOCK
WHERE ( active = true AND system_id = "000000" ):
display
payment_terms.terms_code
payment_terms.description
.
END.
You will see what the query actually returns. (WRITE-JSON is adding a layer after the query.) You will likely discover that your data contains something unexpected.
To my eye the "%" looks more like formatting -- the terms are likely 0.4%.
You then seem to have some issues in the contents of the description field. My guess is that there was a code page mismatch when the user entered the data and that there is gibberish in the field as a result.
Related
I have the correct result coming back. I just need to convert 6 abbreviations in that result to their correct names. There are 20k names assigned to 1 of 6 abbreviated names.
I tried aliasing but that seems to only work for table names.
I tried doing a case statement but that didn't work.
You need to provide more details (like some sample input and output), but if you have data like EM100, and you want to make it EMPLOYEE 100, then you could use an expression such as:
CASE WHEN ColumnName like 'EM%' THEN 'EMPLOYEE ' + SUBSTRING (ColumnName,3,100)
WHEN ColumnName like 'RN%' THEN 'REGNURSE' + SUBSTRING (ColumnName,3,100)
else ColumnName END
But providing more details will help provide a more specific answer.
DEFINE TEMP-TABLE ttservice NO-UNDO
FIELD ad-num AS CHARACTER
INDEX ttprimary AS UNIQUE ad-num .
ASSIGN ttservice.ad-num = vehicles.ad-num NO-ERROR
In this, how to avoid error messages when i am adding duplicate records,
situation is:
when i try to add the duplicate records in temp table it doesnot accept,it is ok ,but it display error messages while running a program,iwant to suppres that error messages.,and avoid the duplicate adding records
You can test for the existence of a duplicate key before you try to create it.
(Filling in the blanks.)
DEFINE TEMP-TABLE ttservice NO-UNDO
FIELD ad-num AS CHARACTER /* you have a "num" field defined as character? that's misleading */
INDEX ttprimary AS UNIQUE ad-num .
for each vehicle no-lock: /* perhaps ad-num is non-unique in the vehicle table? */
find ttservice where ttservice.ad-num = vehicles.ad-num no-error.
if available ttservice then
do:
message "oops!". /* or whatever it is you want when a duplicate occurs... */
end.
else
do:
create ttservice.
ASSIGN ttservice.ad-num = vehicles.ad-num.
end.
end.
Here's another way to get unique ad-num values from the vehicles table:
DEFINE TEMP-TABLE ttservice NO-UNDO
FIELD ad-num AS CHARACTER
INDEX ttprimary AS UNIQUE ad-num .
FOR EACH vehicles NO-LOCK
BREAK BY vehicles.ad-num:
IF FIRST-OF(vehicles.ad-num) THEN
DO:
CREATE ttservice.
ASSIGN ttservice.ad-num = vehicles.ad-num.
END.
END.
Two valued answers have already been added by great professionals but i would like to add mine with minor changes.
def TEMP-TABLE ttservice NO-UNDO
FIELD iservid AS INT
INDEX tt-primary AS UNIQUE iservid.
VEHICLELOOP:
for each vehicles use-index <index-name>
NO-LOCK:
IF CAN-FIND(first ttservice
where ttservice.iservid = vehicles.iservid)
THEN
NEXT VEHICLELOOP.
ELSE DO:
create ttservice.
ASSIGN ttservice.iservid = vehicles.iservid.
END. /* VEHICLELOOP */
So I read the answers and think they're sufficient to fix your particular issue. But here's the general way of thinking you should assume when coding for Progress OpenEdge:
Adding no-error to statements (when they allow it) will "suppress errors", though sometimes they're inevitable and suppressing does no good to the stability of your application, always think of treating them (and displaying errors is a part of this).
Whether you choose to check for existence of a record prior to creation or just set your query to not iterate for undesired (repeated) records is up to you. I advise you to check for performance with different approaches (especially in doing a for each for a large table) to see which one is more satisfactory.
So here's my personal suggestion:
for each vehicles no-lock:
if can-find(first ttService where ttService.ad-num = vehicles.ad-num) then
next.
create ttService.
assign ttService.ad-num = vehicles.ad-num no-error.
if error-status:error then
message "Something went horribly wrong:" + error-status:get-message(1)
view-as alert-box error.
end.
In my example above, the error will only be shown if the assign actually fails. It is not likely to happen, I just wanted to show how the usage of no-error (and its treatment) works.
Anyway, hope it helps!
Some context before the question.
Imagine file FileA having around 50 fields of different types. Instead of all programs using the file, I tried having a service program, so the file could only be accessed by that service program. The programs calling the service would then receive a DataStructure based on the file structure, as an ExtName. I use SQL to recover the information, so, basically, the procedure would go like this :
Datastructure shared by service program :
D FileADS E DS ExtName(FileA) Qualified
Procedure called by programs :
P getFileADS B Export
D PI N
D PI_IDKey 9B 0 Const
D PO_DS LikeDS(FileADS)
D LocalDS E DS ExtName(FileA) Qualified
D NullInd S 5i 0 Array(50) <-- Since 50 fields in fileA
//Code
Clear LocalDS;
Clear PO_DS;
exec sql
SELECT *
INTO :LocalDS :nullind
FROM FileA
WHERE FileA.ID = :PI_IDKey;
If SqlCod <> 0;
Return *Off;
EndIf;
PO_DS = LocalDS;
Return *On;
P getFileADS E
So, that procedure will return a datastructure filled with a record from FileA if it finds it.
Now my question : Is there any way I can assign the %nullind(field) = *On without specifying EACH 50 fields of my file?
Something like a loop
i = 1;
DoW (i <= 50);
if nullind(i) = -1;
%nullind(datastructure.field) = *On;
endif;
i++;
EndDo;
Cause let's face it, it'd be a pain to look each fields of each file every time.
I know a simple chain(n) could do the trick
chain(n) PI_IDKey FileA FileADS;
but I really was looking to do it with SQL.
Thank you for your advices!
OS Version : 7.1
First, you'll be better off in the long run by eliminating SELECT * and supplying a SELECT list of the 50 field names.
Next, consider these two web pages -- Meaningful Names for Null Indicators and Embedded SQL and null indicators. The first shows an example of assigning names to each null indicator to match the associated field names. It's just a matter of declaring a based DS with names, based on the address of your null indicator array. The second points out how a null indicator array can be larger than needed, so future database changes won't affect results. (Bear in mind that the page shows a null array of 1000 elements, and the memory is actually relatively tiny even at that size. You can declare it smaller if you think it's necessary for some reason.)
You're creating a proc that you'll only write once. It's not worth saving the effort of listing the 50 fields. Maybe if you had many programs using this proc and you had to create the list each time it'd be a slight help to use SELECT *, but even then it's not a great idea.
A matching template DS for the 50 data fields can be defined in the /COPY member that will hold the proc prototype. The template DS will be available in any program that brings the proc prototype in. Any program that needs to call the proc can simply specify LIKEDS referencing the template to define its version in memory. The template DS should probably include the QUALIFIED keyword, and programs would then use their own DS names as the qualifying prefix. The null indicator array can be handled similarly.
However, it's not completely clear what your actual question is. You show an example loop and ask if it'll work, but you don't say if you had a problem with it. It's an array, so a loop can be used much like you show. But it depends on what you're actually trying to accomplish with it.
for old school rpg just include the nulls in the data structure populated with the select statement.
select col1, ifnull(col1), col2, ifnull(col2), etc. into :dsfilewithnull where f.id = :id;
for old school rpg that can't handle nulls remove them with the select statement.
select coalesce(col1,0), coalesce(col2,' '), coalesce(col3, :lowdate) into :dsfile where f.id = :id;
The second method would be easier to use in a legacy environment.
pass the key by value to the procedure so you can use it like a built in function.
One answer to your question would be to make the array part of a data structure, and assign *all'0' to the data structure.
dcl-ds nullIndDs;
nullInd Ind Dim(50);
end-ds;
nullIndDs = *all'0';
The answer by jmarkmurphy is an example of assigning all zeros to an array of indicators. For the example that you show in your question, you can do it this way:
D NullInd S 5i 0 dim(50)
/free
NullInd(*) = 1 ;
Nullind(*) = 0 ;
*inlr = *on ;
return ;
/end-free
That's a complete program that you can compile and test. Run it in debug and stop at the first statement. Display NullInd to see the initial value of its elements. Step through the first statement and display it again to see how the elements changed. Step through the next statement to see how things changed again.
As for "how to do it in SQL", that part doesn't make sense. SQL sets the values automatically when you FETCH a row. Other than that, the array is used by the host language (RPG in this case) to communicate values back to SQL. When a SQL statement runs, it again automatically uses whatever values were set. So, it either is used automatically by SQL for input or output, or is set by your host language statements. There is nothing useful that you can do 'in SQL' with that array.
I've got a buffer which contains a mix of data, number and character fields. I am getting the displaying the values of the fields, but for some reason date fields return "?" when I try to add them to a string.
I still get ? even if I do
ASSIGN lvString = lvString + STRING( hField:BUFFER-VALUE ).
I've also tried assigning the BUFFER-VALUE to a local DATE variable, and converting that to a string, but that doesn't work either - still ?.
However if I use the STRING-VALUE attribute, it works fine.
How do I get the value out as a date field, rather than just a string?
There are two ways that you can use to achieve your needs. One is to use directly the table buffer and the other is to use an QUERY handle.
First example using a buffer directly from a table (or a TEMP-TABLE, doesn't matter):
DEF VAR dateVar AS DATE NO-UNDO.
FIND FIRST job NO-LOCK.
dateVar = DATE(BUFFER job:BUFFER-FIELD('dt-job'):BUFFER-VALUE).
MESSAGE dateVar
VIEW-AS ALERT-BOX INFO BUTTONS OK.
Second example using a query handle:
DEF VAR dateVar AS DATE NO-UNDO.
DEF QUERY qrJob FOR job.
OPEN QUERY qrJob FOR EACH job.
QUERY qrJob:GET-FIRST().
dateVar = DATE(QUERY qrJob:GET-BUFFER-HANDLE(1):BUFFER-FIELD('dt-job'):BUFFER-VALUE).
MESSAGE dateVar
VIEW-AS ALERT-BOX INFO BUTTONS OK.
As Tim Kuehn said you can substitute 'dt-job' by # of field in the query if you know its position inside the query. I could used BUFFER-FIELD(2) in substitution of BUFFER-FIELD('dt-job') because dt-job is the #2 field in my query. Keep in mind that use the FIELDS clause in a FOR EACH or in an OPEN QUERY statement changes the order of fields in query. Generally, for browsers only available the columns fields specified in FIELDS section, in order.
These might work for you. It's important to say that BUFFER-VALUE always returns a CHARACTER data type and because of this you need to use DATE statement for data conversion.
Hope it helps.
The standard form for getting a data of the field's data type is
buffer table-name:buffer-handle:buffer-field("field-name"):buffer-value.
for arrays it's:
buffer table-name:buffer-handle:buffer-field("field-name"):buffer-value[array-element].
You can also substitute a field # for "field-name" to get the buffer field handle.
Just some background information. My table, (HireHistory) has 50 columns in it (horizontal). I have a Form (HireHistoryForm) which has a 2 text boxes (HistoryMovieID and HistoryCustomerID) and a button (the button runs the query 'HireHistoryQuery')
Here's an excerpt of my data (the CustomerID's are along the top):
So what I need is so that if a number is entered into the HistoryCustomerID box, then it displays that column. e.g. if the value entered is '1', then in my query it will show all records from column 1.
If a number is entered into the HistoryMovieID box (e.g. 0001) then it displays all instances of that MovieID for the specific CustomerID's. i.e. In column 1 is the ID's, so for ID=1 it will show "0001 on 19/05/2006" then will go on to find the next instance of '0001' etc.
For the HistoryCustomerID I tried to put this into my 'Field' for the query:
=[Forms]![HireHistoryForm]![HistoryCustomerID]
But it didn't work. My query just returned a column labelled '10' and the rows were just made up of '10'.
If you could help I'd greatly appreciate it. :)
No offense intended (or as little as possible, anyway), but that is a horrible way to structure your data. You really need to restructure it like this:
CustomerID MovieID HireDate
---------- ------- --------
1 0001 19/05/2006
1 0003 20/10/2003
1 0007 13/08/2003
...
2 0035 16/08/2012
2 0057 06/10/2012
...
If you keep your current data structure then
You'll go mad, and
It's extremely unlikely that anyone else will go anywhere near this problem.
Edit
Your revised data structure is a very slight improvement, but it still works against you. Consider that in your other question here you are essentially asking for a way to "fix" your data structure "on the fly" when you do a query.
The good news is that you can run a bit of VBA code once to convert your data structure to something workable. Start by creating your new table, which I'll call "HireHistoryV2"
ID - AutoNumber, Primary Key
CustomerID - Number(Long Integer), Indexed (duplicates OK)
MovieID - Text(4), Indexed (duplicates OK)
HireDate - Date/Time, Indexed (duplicates OK)
The VBA code to copy your data to the new table would look something like this:
Function RestructureHistory()
Dim cdb As DAO.Database, rstIn As DAO.Recordset, rstOut As DAO.Recordset
Dim fld As DAO.Field, a() As String
Set cdb = CurrentDb
Set rstIn = cdb.OpenRecordset("HireHistory", dbOpenTable)
Set rstOut = cdb.OpenRecordset("HireHistoryV2", dbOpenTable)
Do While Not rstIn.EOF
For Each fld In rstIn.Fields
If fld.Name Like "Hire*" Then
If Not IsNull(fld.Value) Then
a = Split(fld.Value, " on ", -1, vbBinaryCompare)
rstOut.AddNew
rstOut!CustomerID = rstIn!CustomerID
rstOut!MovieID = a(0)
rstOut!HireDate = CDate(a(1))
rstOut.Update
End If
End If
Next
Set fld = Nothing
rstIn.MoveNext
Loop
rstOut.Close
Set rstOut = Nothing
rstIn.Close
Set rstIn = Nothing
Set cdb = Nothing
MsgBox "Done!"
End Function
Note: You appear to be using dd/mm/yyyy date formatting, so check the date conversions carefully to make sure that they converted properly.