I have a requirement like inserting a large data from visual prolog end to the oracle database and also most importantly all the data needs to be injected through a single stored procedure call. I have tried them passing the data as string values, but there is a constraint in visual prolog like the length the string variable cannot exceed '250' characters. So passing them as strings is not viable for my requirement. so I tried passing the data in the form of prolog list using term_str(). But unfortunately the list/array item is not handled at the oracle end. My DBA has suggested me to pass the large data in the form of an array objects.
Do anybody have an idea how to convert the array data into an array object in visual prolog. or any other recommendations for inserting the large data into database through a single stored procedure call??
Not sure about Visual Prolog, but for SWI there is a nice
chapter in the manual on the ODBC
Related
I have a dynamic stored procedure, which I'm using to run multiple select queries. I have defined something like below.
CREATE PROCEDURE DYNAMIC
(IN IN_COLUMN1 VARCHAR(150),
IN IN_COLUMN2 VARCHAR(500),
IN IN_COLUMN3 VARCHAR(500),
IN IN_COLUMN4 CHAR(08),
IN IN_COLUMN5 DATE,
IN IN_COLUMN6 CHAR(05),
OUT OUT_COLUMN1 CHAR(01),
OUT OUT_COLUMN2 DEC(4,0),
OUT OUT_COLUMN3 DEC(4,0),
OUT OUT_COLUMN4 CHAR(04),
OUT OUT_COLUMN5 DATE
The problem here, when I run Query1, I will have input passed from COBOL DB2 program in IN_COLUMN1,IN_COLUMN2,IN_COLUMN3 and OUTPUT will be fetched into OUT_COLUMN1. I will initialize all INPUT in program, Due to the other OUTPUT parameters like OUT_COLUMN2,OUT_COLUMN3,OUT_COLUMN4 and OUT_COLUMN5 will have null, I'm getting SQLCODE "-305".
To fix this I tried to set OUTPUT parameters to default like below and got error while deploying.
OUT OUT_COLUMN2 DEC(4,0) DEFAULT NULL,
Is there any way to handle this. I'm using COBOL to call the stored procedure running in DB2.
Assuming IBM Enterprise COBOL,
To handle null values in COBOL host variables in SQL you need to assign a "null indicator" for each nullable variable.
See: Using host variables in SQL Statements (with examples in COBOL).
The null indicator will typically be negative if the result variable is null.
By default, all parameters to a DB2 for z/OS Native SQL Stored Procedure are nullable. (Db2 for z/OS 12.0.0 - Creating Native SQL Procedures)
For other ways of solving what I perceive is the task at hand,
Whilst I think at least DB2 User-defined Functions may support function overloading, stored procedures does not. That could have been an alternative.
Otherwise might I suggest returning a dynamic result set from your stored procedure? Then it would be up to the caller of the stored procedure to handle different configurations of the result sets, which is totally doable in COBOL.
Regarding UDF Overloading:
"A schema can contain several functions that have the same name but each of which have a different number of parameters or parameters with different data types. Also, a function with the same name, number of parameters, and types of parameters can exist in multiple schemas."
https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/sqlref/src/tpc/db2z_functionresolution.html
Hope it was to some help.
I need to have a Text data type column (instead of an Lvarchar, for space reasons) in a table. But I have a problem. If I pass the insert/select statement from C#, with the parameter being a string, the connector will do the type conversion automatically and everything works fine.
But I want to have it on a stored procedure. Although, it doesn't let me:
have a Text data type as an input parameter;
have load/unload statements in a stored procedure (that way I could just pass the string and unload and then load it to the table);
can't seem to make a data type conversion in informix...
So... Given this situation, how can I possibly do this? I'm aware that a Text data type is hell to work with but it's also great for saving storage space and not pre-setting a size limit. Correct me if I'm mistaken, as I'm new to Informix.
In this case, I just need to save text (which may or may not be big/small) and return it when needed. Don't need to work it in any way other than that.
I have a really long insert query with more than 40 fields (from an 'inherited' Foxpro database) processed using OleDb, that produces the exception 'Data type mismatch.' Is there any way to know which field of the query is producing this exception?
By now I'm using the force brute method of reducing the number of fields on the insert until I locate the buggy one, but I guess it must be a more straight way to found it...
There isn't really any shortcut beyond taking a guess at which 20 might be the problem, chopping out the other 20 and testing, and repeating that reductive process until you hit it.
Or alternatively looking at the table structure(s) in the DBF and making sure the field types match to the OleDB types you're using. The details of how .NET types are mapped to Visual FoxPro table field types is here.
If you have access to the Visual FoxPro IDE you could probably do that a lot quicker by knocking up a little program or even just doing it in the Command Window.
You are not telling us the language you use, so that we could possibly give a sample to handle it.
Basically what you would do is:
Get the structure,
Parse the insert statement and get values,
Compare data types.
It should be a short code to make this check.
I have written an application in Delphi 2010 that imports data from one database to another. I've done this before many times: From Access to Acces, Access to SQL Server. But now I have to import data from SQL Server 2005 to Oracle 10G. I do this by selecting all the rows from a table in SQL Server database and inserting them one by one to a table with the same structure in Oracle database. The import performs normally except for that I get question marks for some unicode characters. When I insert those characters in the database manually it shows them properly. It's something between Delphi and Oracle. I use UniDac component set for this purpose. Does anybody know the reason for those question marks?
Basically two possibilities: either the character encoding is wrong, or the software used to display the text is using a font (or set of fonts) that does not contain all the characters. To check this, copy some of the displayed text containing the problem characters into another program, like MS Word, and see if it displays them. Set Word to use Arial Unicode MS if needed.
As far as I know, strings are immutable in Delphi. I kind of understand that means if you do:
string1 := 'Hello';
string1 := string1 + " World";
first string is destroyed and you get a reference to a new string "Hello World".
But what happens if you have the same string in different places around your code?
I have a string hash assigned for identifying several variables, so for example a "change" is identified by a hash value of the properties of that change. That way it's easy for me to check to "changes" for equality.
Now, each hash is computed separately (not all the properties are taken into account so that to separate instances can be equal even if they differ on some values).
The question is, how does Delphi handles those strings? If I compute to separate hashes to the same 10 byte length string, what do I get? Two memory blocks of 10 bytes or two references to the same memory block?
Clarification: A change is composed by some properties read from the database and is generated by an individual thread. The TChange class has a GetHash method that computes a hash based on some of the values (but not all) resulting on a string. Now, other threads receive the Change and have to compare it to previously processed changes so that they don't process the same (logical) change. Hence the hash and, as they have separate instances, two different strings are computed. I'm trying to determine if it'd be a real improvement to change from string to something like a 128 bit hash or it'll be just wasting my time.
Edit: Version of Delphi is Delphi 7.0
Delphi strings are copy on write. If you modify a string (without using pointer tricks or similar techniques to fool the compiler), no other references to the same string will be affected.
Delphi strings are not interned. If you create the same string from two separate sections of code, they will not share the same backing store - the same data will be stored twice.
Delphi strings are not immutable (try: string1[2] := 'a') but they are reference-counted and copy-on-write.
The consequences for your hashes are not clear, you'll have to detail how they are stored etc.
But a hash should only depend on the contents of a string, not on how it is stored. That makes the whole question mute. Unless you can explain it better.
As others have said, Delphi strings are not generally immutable. Here are a few references on strings in Delphi.
http://blog.marcocantu.com/blog/delphi_super_duper_strings.html
http://conferences.codegear.com/he/article/32120
http://www.codexterity.com/delphistrings.htm
The Delphi version may be important to know. The good old Delphi BCL handles strings as copy-on-write, which basically means that a new instance is created when something in the string is changed. So yes, they are more or less immutable.