PeopleSoft Query Manager - string expression, trying to get the third set of || - peoplesoft

In PeopleSoft I am trying to get some text from the middle of a cell. I'm having trouble with creating a string expression to do this. The data in the cell looks like this (I've bolded what I'm trying to capture):
|| SVP: Person Number one|| Interview Completed by: Person Number two
|| Info: Employee lists off a bunch of stuff.
|| Non-Relevant Question? Y
|| Manager provided data to: Person Number three
I've submitted a question here and I've come close. Here's what I have so far:
substring(J.HR_NP_NOTE_TEXT,CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100),CHARINDEX('||',J.HR_NP_NOTE_TEXT)
The problem is that this is not stopping at the ||. A better solution - if I knew how - would be if I could get the text that is after the third set of '||' and stop before the fourth set of '||'.

Without seeing your actual output, I think that you will find that your issue is to do with the way substring actually works.
From the Transact SQL documentation I can see online (https://learn.microsoft.com/en-us/sql/t-sql/functions/substring-transact-sql?view=sql-server-2017)
substring takes 3 arguments:
SUBSTRING ( expression ,start , length )
you have the expression - J.HR_NP_NOTE_TEXT
you have the start - CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100) - I'm not 100% sure why you are only looking for the '|| Info:' after 100 characters though?
But then when you calculate the length - CHARINDEX('||',J.HR_NP_NOTE_TEXT) you are not going to get what you expect. Assuming that it ignores the earlier ||'s in the string (will it?), it will return a position in the string, not an actual length.
A more appropriate calculation would be something like
(CHARINDEX('||',J.HR_NP_NOTE_TEXT)-CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100))
i.e. the difference between detecting the '|| Info:' position and the next '||'.
Making your whole query:
substring(J.HR_NP_NOTE_TEXT,CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100),(CHARINDEX('||',J.HR_NP_NOTE_TEXT)-CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100)).
As I'm not entirely sure about your CHARINDEX looking for '||', I would probably try this one though - to find the next '||' after '|| Info:'
substring(J.HR_NP_NOTE_TEXT,CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100),(CHARINDEX('||',J.HR_NP_NOTE_TEXT,CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100))-CHARINDEX('|| Info:',J.HR_NP_NOTE_TEXT)+8,100)).
Although this is a question you're asking about a PS Query, you may get better answers from people who are focused primarily on the SQL language you're using too, as this is not strictly speaking a PeopleSoft only question.
Hope that helps!

Related

How to implement INSERT where not exists for ORACLE in Mule4

I am trying to implement a use-case in Mule4 where a tour needs to be assigned to a user if it has not already been assigned.
I was hoping that I could implement it using Mule db:insert component and using INSERT WHERE NOT EXISTS SQL script as below.
INSERT INTO TL_MAPPING_TOUR(TOURNO,TLID,SYSTEM) select :tourno,:tlid,:system from DUAL
where not exists(select * from TL_MAPPING_TOUR where (TOURNO=:tourno and TLID=:tlid and SYSTEM=:system))
However, this is resulting in Mule Exception
Message : ORA-01722: invalid number
Error type : DB:BAD_SQL_SYNTAX
TL_MAPPING_TOUR table has an id column (Primary Key), but that is auto-generated by a sequence.
The same script, modified for running directly in SQL developer, as shown below, is working fine.
INSERT into TL_MAPPING_TOUR(TOURNO,TLID,SYSTEM)
select 'CLLO001474','123456789','AS400'
from DUAL
where not exists(select * from TL_MAPPING_TOUR where (TOURNO='CLLO001474' and TLID='123456789' and SYSTEM='AS400'));
Clearly Mule db:insert component doesn't like the syntax, but it's not very clear to me what is wrong here. I can't find any INSERT WHERE NOT EXISTS example implementation for the Mule4 Database component either.
stackoverflow page https://stackoverflow.com/questions/54910330/insert-record-into-sql-server-when-it-does-not-already-exist-using-mule directs to page not found.
Any idea what is wrong here and how to implement this in Mule4 without using another Mule4 db:select component before db:insert?
I don't know "mule4", but this:
Message : ORA-01722: invalid number
doesn't mean that syntax is wrong (as you already tested it - the same statement works OK in another tool).
Cause: You executed a SQL statement that tried to convert a string to a number, but it was unsuccessful.
Resolution:
The option(s) to resolve this Oracle error are:
Option #1: Only numeric fields or character fields that contain numeric values can be used in arithmetic operations. Make sure that all expressions evaluate to numbers.
Option #2: If you are adding or subtracting from dates, make sure that you added/substracted a numeric value from the date.
In other words, it seems that one of columns is declared as NUMBER, while you passed something that is a string. Oracle performed implicit conversion when you tested the statement in SQL Developer, but it seems that mule4 didn't and hence the error.
The most obvious cause (based on what you posted) is putting '123456789' into TLID as other values are obviously strings. Therefore, pass 123456789 (a number, no single quotes around it) and see what happens. Should work.
SQL Developer is too forgiving. It will convert string to numbers and vise versa automatically when it can. And it can a lot.
Mulesoft DB connector tries the same but it is not as succefule as native tools. Pretty often it fails to convert, especially on dates but this is not your case.
In short - do not trust too much data sense of Mulesoft. If it works - great! Otherwise try to eliminate any intelligence from it and do all conversions in the query and better from the string. Usually number works fine but if doesn't - use to_number function to mark properly that this is the number.
More about this is here https://simpleflatservice.com/mule4/AvoidCoversionsOrMakeThemNative.html

age control 2 for pl/sql

i am trying to find out at what age an employee started working.
if he started under 16 he should report this 'Error when entering the date of birth' mistake. so my trigger is created but my trigger is not working
I get ever this error: ORA-01422: Exact retrieval returns more than the requested number of lines
i can't find the problem
Here is the code:
SET SERVEROUTPUT ON
ACCEPT Birthday PROMPT ' Pleas give you Date of birth: '
CREATE OR REPLACE TRIGGER T_Controll
before INSERT ON meine_Firma -- Table
FOR EACH ROW
DECLARE
V_Berufstart meine_Firma.Hiredate%TYPE; --Job begin
V_Geburtsdatum DATE; -- Date of birth
V_Alter number:=0; -- AGE
SELECT HIREDATE INTO V_Berufstart FROM meine_Firma;
BEGIN
V_Geburtsdatum:=('&Birthday');
V_Alter:= Round(MONTHS_BETWEEN(V_Berufstart,V_Geburtsdatum)-2)/12;
IF 16 > V_Alter THEN
RAISE_APPLICATION_ERROR(-20201,'Error when entering the date of birth');
END IF;
END;
/
SET SERVEROUTPUT OFF
If he under 16 then he may not work
sorry my english is not good (=
You have a much bigger issue in this script than the error you are getting. Even after correcting as #ShaunPeterson suggested it will still fail
, it WILL NOT generate an error it will just not run as you expect. The issue is you failed to understand substitution variables - the use of &name (Specifically here &Birthday.) I'll actually use &Birthday in the following but the discussion applies to ANY/ALL substitution variables.
people fail to understand why they can't use the "&" substitution
variables in their PL/SQL procedures and functions to prompt for input
at run time. This article will hopefully help clarify in your mind
what the differences are so that you can understand where and when to
use these.
Substitution Variables The clue here is in the name... "substitution". It relates to values being substituted into the code
before it is submitted to the database. These substitutions are
carried out by the interface being used
The effect of this substitution is the the line containing the substitution variable is physically rewritten by the interface replacing %Birthday. In this case if you don't enter a value or the date 2000-05-19 the statement before and after substitution is
BEFORE: V_Geburtsdatum:=('&Birthday');
AFTER: V_Geburtsdatum:=(''); OR V_Geburtsdatum:=('2000-05-19');
Either way the after is what the compiler sees; it does NOT see %Birthday at all. Moreover when run the trigger will not prompt for a value. As far as the compiler is concerned it is a hard coded value that will never change. Beyond that a trigger, or any other PLSQL script (stored or anonymous) never prompts for values, they are actually incapable of doing so as it is not part of the language. Any prompt is via your interface software not plsql.
I'm going to suggest a way to avoid the trigger altogether. Getting on soap box: Triggers are BAD, they have some usefulness for assigning auto incrementing keys (before 12c),logging, very limited auditing, etc. However, for business rules they should be the option of last resort. Ok Get off soap box.
The first thing is to make the columns meine_Firma.Hiredate and meine_Firma.Geburtsdatum NOT null (if not already). If either are NULL you cannot calculate anything with them, the result would be NULL.
Second create a new column age_at_hire (or whatever) as a virtual column then put a check constraint on it. And voila trigger no longer needed. See fiddle for demo.
So the proposed change (YES you will probably have to clean up the bad data first):
alter table meine_Firma modify
( hiredate not null
, Geburtsdatum not null
) ;
alter table meine_Firma add
( age_at_hire integer generated always as (trunc(months_between(hiredate,Geburtsdatum))) virtual
, constraint check_age_at_hire check (age_at_hire >= 16*12)
);
Anyway, I hope you get an understanding of substitution variables for the future. And learn to avoid triggers. Good luck.
The reason you are getting that specific error is that the below select will select ALL rows from meine_Firma as there is no where clause
SELECT HIREDATE INTO V_Berufstart FROM meine_Firma;
However because you are in a trigger you do not need to select anything you use the :NEW bind variable. So you can just use
V_Berufstart := :NEW.HIREDATE;
If this was an update trigger there would be both a :NEW and :OLD bind variable declared so that you can access the OLD and NEW values. As this is an Insert trigger the :OLD will just be null as there is no old values.

Problem with automated SQLite query via Node Red

Warning, I am a complete noob with SQLite and Node-Red.
I am working on a project to scan and read car license plates. I now have the hardware up and running, it is passing plate information to a very basic SQLite 3 table of two records through Node-Red on a Raspberry Pi 3.
I can run instant queries, where a module sends over an exact query to run, ie
SELECT "License_Plate" FROM QuickDirtyDB WHERE "License_Plate" LIKE "%RAF66%"
This will come back with my plate RAF660, as below
topic: "SELECT "License_Plate" FROM QuickDirtyDB WHERE "License_Plate" LIKE "%RAF66%""
payload: array[1]
0: object
License_Plate: "RAF660"
When I automate and run this query it will not work, have been playing with this for three days now.
I am even unable to get a very basic automated query to work like
'var readlpr = msg.payload;
msg.topic = 'SELECT "License_Plate" FROM QuickDirtyDB WHERE "License_Plate" = ' + readlpr + ''
return msg;'
that's two single quotes at the end of the query line.
This is sent through to the query as below, it is the output from the debug node, exactly what is going into the query.
"SELECT "License_Plate" FROM QuickDirtyDB WHERE "License_Plate" = RAF660 "
and the error that comes out is,
"Error: SQLITE_ERROR: no such column: RAF660"
After this is working, I need to work out how I can allow a mismatch of two characters in case the OCR software either misread two characters or even drops two characters entirely. Is this something that a query can handle, or will I have to pass many plate details to a program to work out if I have a match?
I thought I would have had to run a query to create some kind of a view and then requery my read plate vs that view to see which plate in the database is the closest match, not sure if I have the terminology correct, view, join, union etc.
Thank you for looking and any suggestions you may have.
I will probably be going home in about an hour, so may not be able to check back in till Monday
RAF660 is a string and needs to be quoted "RAF660"
License_Plate is a column and should not be quoted.
The way you have it reads as fetch the rows where the RAF660 column is set to the value "License_Plate".

Optimizing String search in oracle

I have a view that contain all data related to employee.
it had about 350k records.
I have to make a name search functionality.
That will retrieve all the data that matches the keyword entered.
The query performance is very slow it takes 15-20 seconds to retrieve data.
Cost-15000
My query:
SELECT H.PERSON_ID,
B.EMPLOYEE_ID,
INITCAP(B.FIRST_NAME) EMP_FNAME,
INITCAP(B.MIDDLE_NAME) EMP_MNAME,
INITCAP(B.LAST_NAME) EMP_LNAME,
B.EMPLOYEE_TYPE PERSON_DESC,
B.EMPLOYMENT_STATUS STATUS_TYPE,
EA.BASE_BRANCH
FROM EMPLOYEE_BASIC_DTLS B,
EMP_ASSIGNMENT_DTLS_MV EA,
EMPLOYEE_HIS_DEPNDENT_TBL H
WHERE B.PERSON_ID = EA.PERSON_ID
AND B.PERSON_ID = H.PERSON_ID
AND ((UPPER(B.FIRST_NAME) LIKE
('%' || V_SEARCH_PARAM1 || '%')) OR
(UPPER(B.MIDDLE_NAME) LIKE
('%' || V_SEARCH_PARAM1 || '%')) OR
(UPPER(B.LAST_NAME) LIKE
('%' || V_SEARCH_PARAM1 || '%')))
AND TRUNC(SYSDATE) BETWEEN EA.EFFECTIVE_START_DATE AND
EA.EFFECTIVE_END_DATE
AND UPPER(H.RELATIONSHIP_CODE) = 'A';
Since EMPLOYEE_BASIC_DTLS is a view I cant use indexing.
While it's true you can't put an index on a view, you can certainly put indexes on the underlying tables. However, as noted by #JustinCave even if you do add indexes to the appropriate tables this query still won't use them because of the use of LIKE. Additionally, because the UPPER function is being applied to the FIRST_NAME, MIDDLE_NAME, and LAST_NAME columns you'd need to define your indexes as function-based indexes. For example, if the 'real' table accessed by the EMPLOYEE_BASIC_TABLE view is called EMPLOYEES you could define a function-based index on the FIRST_NAME column as
CREATE INDEX EMPLOYEES_UPPER_FIRST_NAME ON EMPLOYEES (UPPER(FIRST_NAME));
I suggest you consider whether the LIKE comparisons are really needed, as working around those to get better performance is going to be difficult.
If you'd like to investigate Oracle Text indexes you can find the documentation here. I think you'll find it's more suited to document or document fragment indexes, but perhaps it would give you some ideas.
Share and enjoy.
As one may look for any name or any part of a name there is no way to create an index containing the values to be searched beforehand. So that won't help you here. Oracle will do a full table scan to check every single string for a match.
What you can do though is to speed up that scan.
You can speed up a full table scan by parallelizing it via /*+parallel(EMPLOYEE_BASIC_TABLE,4)*/ for instance. (This would be my advice here.)
Or you can avoid a full table scan by having one index per column, well knowing that there are many repeatedly used names, so that every name is scanned just once. Then you would use function based keys on the underlying table as Bob Jarvis suggests, because you are using the upper function on any name. Fastest would be a combined index:
create bitmap index idx_name_search on EMPLOYEE_BASIC_TABLE (upper(first_name || '|' || middle_name || '|' || last_name))
so there is just one index to look up. (You would have to use exactly this expression in your query of course: WHERE upper(first_name || '|' || middle_name || '|' || last_name) like '%JOHN%'.) But still, you don't know what will be searched for in advance, and as '%JOHN%' may effect only 2% of your table data, '%E%' may affect 80%. The optimizer would never know. You could at least guess and have to different select statements, one with a full table hint you'd use when the search string contains at least three letters and one with an index hint you'd use otherwise, for instance.
You see, that gets quite complicated the more you think about it. I suggest to try the parallel hint first. Maybe this already speeds things up sufficiently.

Change "Expiration Date" font color if within 30 days or already expired?

Not sure the best approach to do this, the application is older which is why I'm having so much trouble generating this. I read about doing a CASE statement but I don't have much SQL experience. Any help is appreciated and answers will be respected. Thanks. Also, there's no design to this, the people who wrote the application used placeholders and all the data comes form this huge file, which is beyond me. I don't know why because I've never seen anything like this. It's a monster.
'-
Dim TemplateColumnCDLExpiration As System.Web.UI.WebControls.TemplateColumn
TemplateColumnCDLExpiration = New System.Web.UI.WebControls.TemplateColumn
If Me.AllowSorting Then
TemplateColumnCDLExpiration.SortExpression = "CDLExpiration"
End If
TemplateColumnCDLExpiration.ItemTemplate =
New JAG.WebUI.Controls.IEditGridTemplate(ListItemType.Item,
"CDLExpiration",
JAG.WebUI.Controls.tEditGridItemControlType.Label)
TemplateColumnCDLExpiration.HeaderText = "CDL Expiration"
MyBase.Columns.Add(TemplateColumnCDLExpiration)
'-
OK, I'll give you the answer to your CASE question, but you have to promise that you'll read the considerations below. :)
I'm using Oracle SQL; I don't know if the syntax is different for other SQL implementations. Here's an example of a dummy query to show the syntax:
SELECT
CASE
WHEN (sysdate - TO_DATE('04/09/2013', 'mm/dd/yyyy') > 30) THEN 'red'
ELSE 'black'
END text_color
FROM dual;
The code in the parenthesis after the WHEN is the test. It compares the current date to April 9th and asks, "Is April 9th more than 30 days ago?" If so, it returns 'red' as the value of text_color. If that condition is false, it returns 'black'. Here's a more generalized form:
SELECT
CASE
WHEN (sysdate - :date_to_check > :expiration_days) THEN 'red'
ELSE 'black'
END text_color
FROM :my_table;
Considerations
You don't need this nasty piece of logic in SQL. The check for X number of days passing since the given date is not database logic. Fetching a date is database logic, deciding how many days have elapsed from that date until today could be argued as either DB logic or business logic, but deciding the text color is definitely display logic, meaning you should be modifying your .NET code, not your SQL. What happens if you need to change the display colors? The date check remains the same, but you have to modify...your SQL? SQL modifications should only need to happen if the data that is being retrieved or stored is modified. The bottom line is that this is not a clean separation of concerns.

Resources