How can I write a simple DB2 pl/sql script in DBeaver/DBVisualizer? I am basically trying to create dynamic SQL (in a loop) and then run it. So for this I will need variables such as the SQL string, build, etc. and then run the script that was created dynamically.
Here is an example in SQL Server. I want to write something like this for DB2:
BEGIN
DECLARE #example VARCHAR(15) ;
SET #example = 'welcome' ;
SELECT #example;
END
dbvis lets you develop scripts for Db2.
You need to know some basics.
First you need to tell dbvis that there is an additional statement delimiter other than the default ; semi-colon. Db2 needs to know the difference between the end of an interim-statement and the end of a compound block and for this Db2 uses an additional delimiter/terminator for the end of a block.
You can either specify this block delimiter/terminator inside the script with the #delimiter command (specific to dbvis), or you can configure the delimiter via the dbvis settings GUI (this is the better approach). This depends on the version of your dbvis.
Many people use the # character as the block delimiter when writing compound SQL for Db2 although other characters are possible (as long as it is different from the default semi-colon).
If you want your scripts to be runnable by Db2 command line processor directly without using dbvis (i.e. to run the scripts from the command line shell (cmd.exe or bash/ksh etc) then you would not use the #delimiter command because that is only known to dbvis. The Db2 command line processor understands the syntax --#SET TERMINATOR # to change the delimiter on the fly inside scripts, and it also has a command line option (-td#) to let you specify the alternative delimiter via the command line.
Second you need to be aware of which platform (Db2-for-Z/OS, Db2-for-i, Db2-for-Linux/Unix/Windows/Cloud) that you are targetting, because the features and syntax can differ per platform. When asking for help with Db2 you should always specify the target platform, and stackoverflow has dedicated tags for db2-luw, db2-400, db2-zos.
Third you need to follow either ANSI SQL PL syntax rules (i.e. not transact SQL as used in Microsoft SQL Server), which includes rules on the valid characters for identifier names. On Db2 variables cannot begin with #. If your Db2-server runs on Linux/Unix/Windows, and it has been specially configured in advance, then you can also write your blocks in Oracle PL/SQL syntax and Db2 will emulate that. But at the present time there is no ability in Db2 to emulate Transact-SQL.
Related
I am trying various different options of building Asterisk 11 and these will be deployed on various servers. They are all built from the same sources and have what I presume to be some sort of checksum embedded in the version ID (26dd464).
In order to distinguish the various versions of the executable I would like to add my own version number or string on similar. I note that /usr/src/asterisk/main/version.c specifies a const char [] variable asterisk_version, but if I manually edit this it gets overwritten as part of the make process. Is there a sensible way I could specify some sort of identifying label (e.g. as a parameter passed to make or some such)?
In /usr/src/asterisk/build_tools/make_version_c you can specify it. This script overwrites the file you've mentioned (/usr/src/asterisk/utils/version.c).
I can think of workarounds on how to get this working however I'm interested in finding out if there's a solution to this specific problem.
I've got a go program which requires a json string arguement:
go run main.go "{ \"field\" : \"value\" }"
No problems so far. However, am I able to run from the command line if one of the json values is another json string?
go run main.go "{ \"json-string\" : \"{\"nestedfield\" : \"nestedvalue\"}\" }"
It would seem that adding escape characters incorrectly matches up the opening and closing quotes. Am I minuderstanding how this is done or is it (and this is the side I'm coming down on) simply not possible?
To reiterate, this is a question that has piqued my curiosity - I'm aware of alternative approaches - I'm hoping for input related to this specific problem.
Why don't you just put your json config to the file and provide config file name to your application using flag package
Based on the feedback from wiredeye I went down the argument route instead. I've modified the program to run on:
go run main.go field:value field2:value json-string:"{\"nestedfield\":nestedvalue}"
I can then iterate over the os.Args and get the nested json within my program. I'm not using flags directly as I don't know the amount of inputs into the program which would have required me to use duplicate flags (not supported) or parse the flag to a collection (doesn't seem to be supported).
Thanks wiredeye
I am observing one command in my TCL code (interpreter) . the command name is "interpreter" .
I searched on the google for this command , but I did not get much information .
Can anyone explain about this command ?
Thanks in advance .
Looks like I'm a year late, but maybe you're using Expect, a tcl plugin?
If you follow the link above search for interpreter " with ctrl+f you will find the following (bizarrely formatted) description:
causes the user to be interactively prompted for Expect and Tcl commands. The result of each command is printed.
Actions such as break and continue cause control structures (i.e., for, proc) to behave in the usual way. However return causes interpreter to return to its caller, while inter_return causes interpreter to cause a return in its caller. For example, if "proc foo" called interpreter which then executed the action inter_return, proc foo would return. Any other command causes interpreter to continue prompting for new commands.
By default, the prompt contains two integers.
The first integer describes the depth of the evaluation stack (i.e., how many times Tcl_Eval has been called). The second integer is the Tcl history identifier. The prompt can be set by defining a procedure called "prompt1" whose return value becomes the next prompt. If a statement has open quotes, parens, braces, or brackets, a secondary prompt (by default "+> ") is issued upon newline. The secondary prompt may be set by defining a procedure called "prompt2".
tl;dr: It pauses your script and allows you to execute tcl commands
I have a delimited file as input source to ingest data in marklogic using conten-pump through unix.There is no such column in the file that is unique throught to serve as the URI. Problem with this is that since duplicates(URI) is not possible, those records are skipped/overwritten for that particular URI.
The syntaxes available are:
-delimited_uri_id *my_column_name*
output_uri_prefix *my_prefix_string*
output_uri_suffix *my_suffix_string*
output_uri_replace pattern,'string'
The command for mlcp is:
bin/mlcp.sh import -host localhost -port 8042 -username name -password password-input_file_path hdfs://path/to/file -delimiter '|' -delimited_uri_id column_name-input_file_type delimited_text -mode distributed
The problem that lies here is that if I modify the above command and include:
-output_uri_prefix $(date +%s%N)
It takes the time(in nanoseconds) of execution of this command and prefixes for all URI.But that doesnt solve my problem since this value remains repeated. Same would happen for other options available too .What could be done to have all records ingested by the construction of unique URI for all records in some manner?
One way or another it is up to you to provide unique ids. For a delimited file the easiest answer might be to add a new column and populate it with a unique id, generated however you like.
Or you could use http://marklogic.github.io/recordloader/ DelimitedDataLoader with the special option ID_NAME=#AUTO. But keep in mind that ID_NAME=#AUTO will single-thread ingestion.
I've inherited a large amount of Classic ASP code that is currently missing SQL injection protection, and I'm working on it. I've examined in detail the solutions offered here: Classic ASP SQL Injection Protection
On the database side, I have a Microsoft SQL server 2000 SP4
Unfortunately stored procedures are not an option.
After studying php's mysql_real_escape_string ( http://www.w3schools.com/php/func_mysql_real_escape_string.asp ) , I've replicated its functionality in ASP.
My question(s) are:
1) Does Microsoft SQL server 2000 have any other special characters that need to be escaped that are not present in MySQL ( \x00 , \n , \r , \ , ' , " , \x1a )
2) From an answer in Can I protect against SQL Injection by escaping single-quote and surrounding user input with single-quotes? I read "One way to launch an attack on the 'quote the argument' procedure is with string truncation. According to MSDN, in SQL Server 2000 SP4 (and SQL Server 2005 SP1), a too long string will be quietly truncated."
How can this be used for an attack (I really can't imagine such a scenario) and what would be the right way of protecting against it?
3) Are there any other issues I should be aware of? Any other way of injecting SQL?
Note: A 30-min internet search said that there are no libraries for classic ASP to protect against SQL injection. Is this so, or did I really fail at a basic task of searching?
The best option is to use parameterized queries. On how that is done, you must check out:
SQL Injection Mitigation: Using Parameterized Queries
In PHP also, the PDO (and prepared statements) allows developers to use parameterized queries to avoid sql injection.
Update
Yes you can specify parameters in WHERE clause and for that you can use ADODB.Command object like below example:
' other connection code
set objCommand = Server.CreateObject("ADODB.Command")
...
strSql = "SELECT name, info FROM [companies] WHERE name = ?" _
& "AND info = ?;"
...
objCommand.Parameters(0).value = strName
objCommand.Parameters(1).value = strInfo
...
For more information, see the article link that I have posted above or you may want to research a little more on the topic if you want.
I use two layers of defense:
create a 'cleanparameter' function, and every call that gets from querystring or form values, use it calling that function. The function at the very least should replace simple quotes, and also truncate the string to a value you pass. So, for example, if the field can't be longer than 100 chars, you would call it like x = cleanparameter(request.querystring("x"), 100). That's the first line of defense
Use parameterized queries to run SQL instructions