When running a quick report using such as
where asset_id like '&ASSET_ID%'we receive the error “ORA-01756: quoted string not properly terminated”. The error does not occur when the % wildcard is removed. Using query flags ('&&-CS-L]ASSET_ID%') still results in the same issue. Is there a way to run the report using the wild in the parameter?
This error occurring in all of our reports containing both a user inputted parameters and wildcard since our update to UPD22.
I think you can leave the “%” off of the end.
('&a-CS-L]ASSET_ID')
This works for our Apps 10 UPD17 environment.
I think you can leave the “%” off of the end.
('&a-CS-L]ASSET_ID')
This works for our Apps 10 UPD17 environment.
We would rather not have to change the functionality of our reports if possible. In the example with an ID is doesn’t matter as much but with other reports it could cause problems.
I think you can leave the “%” off of the end.
('&a-CS-L]ASSET_ID')
This works for our Apps 10 UPD17 environment.
We would rather not have to change the functionality of our reports if possible. In the example with an ID is doesn’t matter as much but with other reports it could cause problems.
If I’m understanding correctly, this will not change the functionality of the reports. The flags you’ve set allow for partial searches, so the “%” sign is not needed.
I think you can leave the “%” off of the end.
('&a-CS-L]ASSET_ID')
This works for our Apps 10 UPD17 environment.
We would rather not have to change the functionality of our reports if possible. In the example with an ID is doesn’t matter as much but with other reports it could cause problems.
If I’m understanding correctly, this will not change the functionality of the reports. The flags you’ve set allow for partial searches, so the “%” sign is not needed.
With this, partial searching only world if your input is “1234%” to receive “12345”. With the old report the input could be “1234” and you would still receive “12345”
you can use concatenation.
something like this
where asset_id like '&ASSET_ID'||'%'
Hallo
I use normally this construction in the WHERE-Clause:
report_sys.parse_parameter( coij.company, '&[MC-BL]Company' ) = 'TRUE'
AND ( report_sys.parse_parameter( coij.catalog_no, '&[-C-BL]Catalog_No') = 'TRUE' OR coij.catalog_no IS NULL )
The the user can use this parameter
Company (Mandatory) as '3080' or '2%' or '%' or '1000..3010'
Catalog_No as 'A-81.420.042' or 'A%420.042' or '%' or 'A-24.411.100..A-27.201.010' or empty for ALL
Best Regards,
André
Hi!
In my opinion I would try concatenation
where asset_id like '&ASSET_ID'||'%'
As said
Best regards,
Szymon Grzegorczyk
I think you can leave the “%” off of the end.
('&a-CS-L]ASSET_ID')
This works for our Apps 10 UPD17 environment.
We would rather not have to change the functionality of our reports if possible. In the example with an ID is doesn’t matter as much but with other reports it could cause problems.
If I’m understanding correctly, this will not change the functionality of the reports. The flags you’ve set allow for partial searches, so the “%” sign is not needed.
With this, partial searching only world if your input is “1234%” to receive “12345”. With the old report the input could be “1234” and you would still receive “12345”
Ahh yes, the user will need to enter a ‘%’ when they are searching. I suspect users are familiar with this though as it’s a wildcard that IFS uses. The concatenation of the ‘%’ is a really good idea too, though only if your users are okay with potentially getting back more results than expected.
For example, we have a part number “A10” that is popular. If a user was searching for just A10, then it could bring up hundreds of parts that contain “A10”.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.