Figuring out what this Trim() function is doing? - informix

I have a constraint on a transformer with this:
Trim(CollectFrom.collect_from,"-","A")<=TheDate
Here is what collect_from looks like:
'2017-02-27'
And here is what TheDate looks like:
'20170227'
I am unsure exactly how this Trim() function works. My first guess is that it is giving it the same format as 'TheDate' however I don't understand the "A" argument. Could somebody explain it?

The manual page for TRIM() says that shouldn't work.
When I try to run what you show, I get errors:
SQL[2405]: select trim('2017-02-01', '-', 'A') from dual;
SQL -674: Routine (trim) can not be resolved.
SQLSTATE: IX000 at /dev/stdin:1
SQL[2406]: select trim('2017-02-01', '-') from dual;
SQL -674: Routine (trim) can not be resolved.
SQLSTATE: IX000 at /dev/stdin:2
The manual says you need TRIM({BOTH|LEADING|TRAILING} [char] FROM source):
SQL[2407]: select trim(both '-' from '2017-02-12') from dual;
2017-02-12
SQL[2408]: select trim(both '-' from '2017-02-12-') from dual;
2017-02-12
SQL[2409]: select trim(both '-' from '-2017-02-12-') from dual;
2017-02-12
SQL[2410]:
(The SQL command interpreter used is my SQLCMD.)
There's a chance that someone has defined a TRIM function that takes three arguments — that's not detectable from here. You'd have to look in the system catalog of your database to find that.
OTOH, that doesn't seem to be allowed, either:
SQL[2411]: create function trim(a varchar(10), b varchar(20), c varchar(30)) returning varchar(64);
return trim(leading from a) || ' ' || trim(both from b) || ' ' || trim(trailing from c);
end function;
SQL -9710: Overloading of built-in functions is not allowed.
SQLSTATE: IX000 at /dev/stdin:8
SQL[2412]:

Informix 11.50 has build in trim() function: https://www.ibm.com/support/knowledgecenter/SSGU8G_11.50.0/com.ibm.sqls.doc/ids_sqs_1556.htm But it looks little different from trim() in your question, so I think you use trim() function build by some user.
Normally trim() takes care only at chars at beginning or at end of the string, but in your example trim() had to remove - chars that are in the middle of the string. I guess that last argument A tells trim() to remove all such characters from source string.
To find out what trim() function really do you must find it source. You can do it with some GUI database tools like SQirreL SQL Client (it uses JDBC), you can do it with dbschema Informix utility or with my Python/Jython program that uses ODBC/JDBC: https://code.activestate.com/recipes/576621-dump-informix-schema-to-text
It would be helpful to tell us what version of Informix you use.

Trim(CollectFrom.collect_from,"-","A")
Here A means to Remove all the occurrences of '-' from the input string CollectFrom.collect_from . Hence You are getting '20170227' . Here is the document which would give further more information on Trim function.
https://www.ibm.com/support/knowledgecenter/en/SSZJPZ_11.5.0/com.ibm.swg.im.iis.ds.parjob.dev.doc/topics/r_deeref_String_Functions.html

Related

Execute Hana stored proc with input parameters in ssrs

I cannot seem to get a HANA Stored Procedure to work with input parameters in SSRS by passing parameters via CALL:
Actuaaly my problem is either SSRS or the ODBC driver is having a problem sending/receiving the parameter value.
Other attempts at syntax: call "sp_getdata"() , call "sp_getdata"(?) , call "sp_getdata"(regid) , call "sp_getdata"(#regid)
None of these worked.
If I call the procedure with a hard coded value i.e. call "sp_getdata"(5) - it works.
Again, if the stored procedure has no parameters it works fine.
Can anyone give me any real direction on this issue. A sample of the correct syntax or a step by step example would really be appreciated.
Create the syntax in the Dataset Expression from the Parameter instead of letting SSRS insert the parameter call "sp_getdata"(?)
Use the Expression in the Dataset's Command Text box.
="Call " & CHR(34) & "sp_getdata" & CHR(34) & "(" & Parameters!REG_ID.Value & ")"
The resulting text passed to the server would be (with X for the number):
Call "sp_getdata"(x)

Not able to create stored procedure in DB2

I am trying to create a stored procedure in DB2 using IBM DB2 Cloud. I am getting the error as:
An Unexpected token 'END-OF-STATEMENT' was found following "".
Detail about the error is seen in the screenshot below.
Click here for error screenshot
CREATE PROCEDURE trial_pro(in msg varchar(100))
language sql;
BEGIN
insert into collision values(msg);;
END
First of all:
There ";" behind language sql is wrong.
Two ";" after the line with the insert do not make sense and do not match with the screenshot.
In addition to that: While ";" is the statement terminator inside your stored procedure make sure to choose (configure) another one for the (outer) create procedure statement. Usually the tools you run the SQLs offer a option to change it.
You must change the default statement terminator (;) if you use a compound statement.
In the DSM console you can do it either temporarily for some particular statement:
--#SET TERMINATOR #
CREATE PROCEDURE trial_pro(in msg varchar(100))
language sql
BEGIN
insert into collision values(msg);
END#
--#SET TERMINATOR ;
or set it by default with:
Editor options (gear icon at the top right corner) -> Statement
terminator -> #

Firedac select working with Firebird returns no records

Hello I'm working with Firedac (Delphi Seattle) using Firebird (2.5) as a database, when I run this query using a TFDQuery, no records are returned:
SELECT ID FROM USERS WHERE PWD = 'êHÆ–!+'
The same query within a Database program as IbExpert return one record. Is there some parameter with Firedac components to configure that can solve this issue. Thanks.
It's in the query string and it's the ! char. By default, query strings are preprocessed, and you must escape constant chars like !, &, :, ?, { or }, otherwise they are used as special chars.
Your best option is using parameters. That will (except other benefits) get rid of that ! char from the preprocessed command:
FDQuery.SQL.Text := 'SELECT ID FROM USERS WHERE PWD = :Password';
FDQuery.ParamByName('Password').AsString := 'êHÆ–!+';
FDQuery.Open;
Another option is escaping that constant char or disable macro preprocessor. For more information see the Special Character Processing topic.

Execute immediate 'Create or replace view' gives 00900. 00000 - "invalid SQL statement" error

I have been stuck with this error. Can you please suggest what the mistake is in the code below? This is written inside a procedure that takes input for the variables. Thanks.
execute immediate 'Create or replace view '||p_viewname||' AS
select * from (
select NAME, CODETYPE, CODE
from HLIDEV_VIEWS.V_CONCEPT
WHERE HLIDEV_VIEWS.V_CONCEPT.CONCEPTTYPE = '''||p_concepttype||'''
)
pivot
(
max(code)
for codetype in ('||all_codetypes||')
)';
Update: Below is the error I am seeing.
EXEC "HLIDEV_VIEWS"."FinalCreatePOAView" ('POA_CONCEPT_TYPE','PresentOnAdmission')
Error report -
ORA-00911: invalid character
ORA-06512: at "HLIDEV_VIEWS.FinalCreatePOAView", line 39
ORA-06512: at line 1
00911. 00000 - "invalid character"
*Cause: identifiers may not start with any ASCII character other than
letters and numbers. $#_ are also allowed after the first
character. Identifiers enclosed by doublequotes may contain
any character other than a doublequote. Alternative quotes
(q'#...#') cannot use spaces, tabs, or carriage returns as
delimiters. For all other contexts, consult the SQL Language
Reference Manual.
*Action:
What you are trying to do is perfectly doable using execute immediate. You just have a syntax error somewhere or the table really doesn't exist.
Try writing the string you are building to DBMS_OUTPUT.PUT_LINE instead of sending it to EXECUTE IMMEDIATE. Then, try to run that string as a command in SQL*Plus. That should highlight the error.
FWIW, I don't have your objects in my database, but I wrote an EXECUTE IMMEDIATE with the same form as yours and it works fine in Oracle 11g2.
DECLARE
p_view_name VARCHAR2(61) := 'VXSMIMMCP.MATT_V';
p_region_code VARCHAR2(30) := 'R01';
p_all_port_codes VARCHAR2(400) := '''P01'',''P02'',''P03''';
BEGIN
EXECUTE IMMEDIATE
'Create or replace view '
|| p_view_name
|| ' AS select * from ( select REGION_CODE, account_number , port_code from APPS.XXCUS_ACCOUNTS WHERE APPS.XXCUS_ACCOUNTS.REGION_CODE = '''
|| p_region_code
|| ''' ) pivot ( min(account_number) for port_code in ('
|| p_all_port_codes
|| ') )' ;
END;
Thank you #MatthewMcPeak and #MahendarMahi for your inputs. Suddenly my code started working fine and it created the view the way I wanted. The only thing I did was, as #MahendarMahi suggested, I removed pivot and ran it to see the same error and then replaced pivot and the error was gone. I am sure there is no change in the code but anyhow it weirdly works now. Thank you again for your time.

mysql_real_escape_string when echoing out?

I know I have to use mysql_real_escape_string when running it in a query, for example:
$ProjectHasReservationQuery = ("
SELECT *
FROM reservelist rl
INNER JOIN project p on rl.projectid = p.projectid
WHERE rl.projectid = ". mysql_real_escape_string($record['projectid']) ."
AND restype = 'res'
");
But how about echoing it out, like:
query1 = mysql_query("SELECT * FROM users");
while ($record = mysql_fetch_array($query1 ))
{
echo "".stripslashes(mysql_real_escape_string($record['usersurname']))."";
// OR
echo "".$record['usersurname']."";
}
Which one is it? Personally I think echo "".$record['usersurname']."";, since this is coming FROM a query and not going INTO. But want to be 100% sure.
(I am aware about PDO and mysqli)
I know I have to use mysql_real_escape_string when running it in a query
Quite contrary, you should not use mysql_real_escape_string on a query like this.
It will do no good but leave you with false feeling of safety.
As you can say from the function name, it is used to escape strings, while you are adding a number. So, this function become useless, while your query still remains wide open for injection.
One have to use this function only to format quoted strings in the SQL query.
Thus you can conclude the answer from this rule: no, there is no point in using this function for output.
As for the protection, either treat your number as a string (by quoting and escaping it) or cast it using intval() function.
Or, the best choice, get rid of this manual formatting and start using placeholders to represent dynamical data in the query. it is not necessarily prepared statements - it could use the same escaping, but encapsulated in some placeholder handling function

Resources