The application I'm working on can run on English or French. There is an interactive report that runs fine in English but when the app was ran in French an ORA error occurs saying that one of the columns isn't a valid identifier. When I went to check the debug logs, the resulting SQL when ran in French looks like an older version compared to the resulting SQL when ran in English.
--Original Source
SELECT ...
CASE
WHEN (dependant_pkg.get_dependant_id (ee.memb_id, '0') IS NULL OR ee.re_enrolment_dt >= TRUNC (SYSDATE))
and (( SEC_USER_EXTERNAL_PKG.get_info_vc(:g_user_id,'entity_type_code') = 'AC' ) or not (:g_user_type = 'GR' and :g_brand_code = 'HB' ))
THEN ... --codes
END link,
ee.empl_contact_email
FROM empl_enrol ee, company c
WHERE ...
--FRENCH
SELECT ...
CASE
WHEN (dependant_pkg.get_dependant_id (ee.memb_id, '0') IS NULL OR ee.re_enrolment_dt >= TRUNC (SYSDATE))
and not (:g_user_type = 'GR' and :g_brand_code = 'HB') --! missing/different condiition
THEN ... --codes
END link
--missing column
FROM empl_enrol ee, company c
WHERE ...
--ENGLISH
SELECT ...
CASE
WHEN (dependant_pkg.get_dependant_id (ee.memb_id, '0') IS NULL OR ee.re_enrolment_dt >= TRUNC (SYSDATE))
and (( SEC_USER_EXTERNAL_PKG.get_info_vc(:g_user_id,'entity_type_code') = 'AC' ) or not (:g_user_type = 'GR' and :g_brand_code = 'HB' ))
THEN ... --codes
END link,
ee.empl_contact_email
FROM empl_enrol ee, company c
WHERE ...
Decided to actually post an answer so you could mark this solved.
Apex creates duplicate applications for different languages, thats why translations are mostly done after the app is completed. So you might just be changing the default app, but if you switch the language to french, it reverts to the older version.
You will need to republish the translated app.
Related
When used in where clause
select * from tableA where col like 'value' || col = val ;
select * from tableA where col like 'value' or col = val ;
I experience two different behaviors:
Both 1 & 2 work the same in version ( 10.2.14 )
Only 2 works as expected in version ( 10.3.22 )
I tried to look at release log for 10.3.22 but nothing was mentioned regarding the change to logical OR. Has anyone faced the issue if so just want to confirm there are changes between different versions of Maria DB ?
or its somethign else i shuld be looking at ?
Check that if you have the PIPES_AS_CONCAT SQL_MODE set in the 10.3.22. If not, show the data that is giving you trouble.
According to all examples my query should be executing. I am trying to update new column on my table with the last 4 digits of the phone number like so :
UPDATE users
SET users.phone_last_4 = t.lastFour
FROM
(
select substr( phone_number, -4) as lastFour from users
) t;
Also tried this:
UPDATE users
SET users.phone_last_4 = t.lastFour
FROM
(
select substr( phone_number, -4) as lastFour from users
) AS t;
Both fail with same error :
near ".": syntax error: UPDATE users
SET users.
What could I possibly do wrong here?
SQLite does not support joins for the UPDATE statement and also this syntax containing FROM .
In your case I can't see why you need it.
Just do:
UPDATE users
SET phone_last_4 = substr(phone_number, -4)
I’m working with an Oracle APEX application and today I have discovered that the password verify function, which is set up for several profiles, doesn’t work properly, because the parameter, which stands for the old password, turned out to be null.
My password verify function F_VERIFY_PASSWORD is based on the example from the Oracle admin file utlpwdmg.sql: the code changes were made only for the parts which are not related to the comparison of the old password and the new one. The function code is presented below (excluding the parts which make no problems):
create or replace function F_VERIFY_PASSWORD
(
USERNAME varchar2
,PASSWORD varchar2
,OLD_PASSWORD varchar2
) return boolean is
…
DIFFER integer;
MINDIFFER number := 3;
…
begin
…
-- Check that the new password differs from the previous one no less than in MINDIFFER positions.
if OLD_PASSWORD is not null
then
DIFFER := LENGTH(OLD_PASSWORD) - LENGTH(PASSWORD);
DIFFER := ABS(DIFFER);
if DIFFER < MINDIFFER
then
if LENGTH(PASSWORD) < LENGTH(OLD_PASSWORD)
then
M := LENGTH(PASSWORD);
else
M := LENGTH(OLD_PASSWORD);
end if;
for I in 1 .. M
loop
if SUBSTR(PASSWORD,I,1) != SUBSTR(OLD_PASSWORD,I,1)
then
DIFFER := DIFFER + 1;
end if;
end loop;
if DIFFER < MINDIFFER
then
RAISE_APPLICATION_ERROR(-20011,'The new password must differ from the old one no less than in 3 positions!');
end if;
end if;
end if;
-- Return TRUE, if all is correct.
return(true);
end;
The changing password itself is made by the means of the procedure P_CHANGE_PASS, which is executed in Oracle APEX application. The code of it is presented below (excluding the parts which make no problems).
create or replace procedure P_CHANGE_PASS
(
NEWPASS varchar2
,NEWPASS2 varchar2
,USR varchar2
) as
…
begin
…
--changing the password
begin
execute immediate 'alter user ' || USR || ' identified by ' || NEWPASS;
exception
when others then
…
end;
end;
I’ve tried the following steps to make the verify function include the check of differences between the old and new passwords:
revoked the privilege ALTER USER from the user APEX_PUBLIC_USER;
added the statement AUTHID CURRENT_USER to the code of the
“client” procedure P_CHANGE_PASS;
added REPLACE <old password>
to the ALTER USER command (it’s awful thing, but I made it just
for debugging).
None of these actions helped me to solve my problem. So, what should I do to make the parameter OLD_PASSWORD not null in the function F_VERIFY_FUNCTION?
I use Oracle 11g (version 11.2.0.3.0), Oracle APEX 4.2.6.00.03.
I have a sqlLite database which contain in some field sql statement, this sql statement are needed to create some chart in an IOS Application.
Now I need to display this chart in a web application which use Postgresql
I need to find a script who convert from sqllite syntax to postgresql syntax
things like printf, current date etc...
I am asking if there is some ready to use script for this kind of conversion
PS : I am using Symfony for the back-end so PHP
Example:
SELECT
r.agent AS gebiet,
r.invoiceno AS rechnung,
r.infotext AS auftrag,
c.companyno AS kundenr,
c.companyname AS kunde,
r.itemno AS artikelnr,
r.itemtext AS artikel,
SUM(r.qty) || ' ' || r.unit AS menge,
printf('%.2f', SUM(r.turnover) / SUM(r.qty)) AS preis,
printf('%.2f', SUM(r.turnover)) || ' ' || r.currency AS gesamt,
'2' AS 'sys_align9',
'2' AS 'sys_align10',
'2' AS 'sys_align11'
FROM
invoices r
INNER JOIN
company c
ON
r.companyno = c.companyno
WHERE
r.agent = ?
Disclaimer: I don't know SQLite ;)
The query structure itself looks good, but two things will not work with Postgres:
I assume printf() formats the output to two decimals, so to_char() is probably what you are looking for
identifiers need to be enclosed in double quotes, not single quotes. So AS 'sys_align11' should be `AS "sys_align11" but the quotes are not required to begin with.
SELECT
r.agent AS gebiet,
r.invoiceno AS rechnung,
r.infotext AS auftrag,
c.companyno AS kundenr,
c.companyname AS kunde,
r.itemno AS artikelnr,
r.itemtext AS artikel,
SUM(r.qty) || ' ' || r.unit AS menge,
to_char(SUM(r.turnover) / SUM(r.qty), '0.00') AS preis,
to_char(SUM(r.turnover),'0.00') || ' ' || r.currency AS gesamt,
'2' AS sys_align9,
'2' AS sys_align10,
'2' AS sys_align11
FROM
invoices r
INNER JOIN
company c
ON
r.companyno = c.companyno
WHERE
r.agent = ?
If turnover is an integer (or bigin) you need to cast it to numeric, otherwise the division is done as an integer division, e.g. SUM(r.turnover)::numeric
As you are using an aggregat function you will need some kind of group by in Postgres - otherwise the result wouldn't be deterministic.
If invoiceno is the primary key of the invoices table, a `group by r.invoiceno' should be enough.
(Using Oracle 11.2)
I have a rather complicated SQL with something like
wm_concat( distinct abc )
that is expected to return some varchar2(4000) compatible result.
It causes ORA-00932: inconsistent datatypes in my select used in some coalesce( some_varchar_col, wm_concat( ... ) ).
So I tried casting it via two different methods:
dbms_lob.substr( ..., 4000 ) -- L) tried even with 3000 in case of "unicode byte blow-up"
cast( ... as varchar2(4000)) -- C) tried even with 3000 in case of "unicode byte blow-up"
(The are used in a view, but playing around with it suggests, it is not related to the views)
Depending on the column and other operators I either get N) no result or O) ORA-22922:
select * from view_with_above_included where rownum <= 100
N) My Eclipse Data Explorer JDBC connection returns without any result (no columns without results, no (0 rows effected), only the query time statistics). (It could be an internal exception not treated as such?)
O)
ORA-22922: nonexistent LOB value
ORA-06512: in "SYS.DBMS_LOB", line 1092
ORA-06512: in line 1
Strangely the following test queries work:
-- rownum <= 100 would already cause the above problems
select * from view_with_above_included where rownum <= 10
or
select * from view_with_above_included
but looking at the actual aggregated data does not show aggregated data that would exceed 1000 characters in length.
Luckily, it works with the listagg( ... ) function provided since 11.2 (we are already running on), so we did not have to investigate further:
listagg( abc, ',' ) within group ( order by abc )
(Where wm_concat(...) is, as one should know, some internal and officially unsupported function.)
a rather nice solution (because it is not so bloated) to implement the distinct functionality is via self-referencing regexp functionality which should work in many cases:
regexp_replace(
listagg( abc, ',' ) within group ( order by abc )
, '(^|,)(.+)(,\2)+', '\1\2' )
(Maybe/Hopefully we will see some working listagg( distinct abc ) functionality in the future, which would be very neat and cool like the wm_concat syntax. E.g. this is no problem since a long time with Postgres' string_agg( distinct abc )1 )
-- 1: postgres sql example:
select string_agg( distinct x, ',' ) from unnest('{a,b,a}'::text[]) as x`
If the list exceeds 4000 characters, one cannot use listagg anymore (ORA-22922 again).
But luckily we can use the xmlagg function here (as mentioned here).
If you want to realize a distinct on a 4000-chars-truncated result here, you could outcomment the (1)-marked lines.
-- in smallercase everything that could/should be special for your query
-- comment in (1) to realize a distinct on a 4000 chars truncated result
WITH cfg AS (
SELECT
',' AS list_delim,
'([^,]+)(,\1)*(,|$)' AS list_dist_match, -- regexp match for distinct functionality
'\1\3' AS LIST_DIST_REPL -- regexp replace for distinct functionality
FROM DUAL
)
SELECT
--REGEXP_REPLACE( DBMS_LOB.SUBSTR( -- (1)
RTRIM( XMLAGG( XMLELEMENT( E, mycol, listdelim ).EXTRACT('//text()')
ORDER BY mycol ).GetClobVal(), LIST_DELIM )
--, 4000 ), LIST_DIST_MATCH, LIST_DIST_REPL ) -- (1)
AS mylist
FROM mytab, CFG