Some of my DLL statements related to full text search (ex: CREATE INDEX...FOR TEXT) only run when executed from db2ts. I'd like to emit these statements directly from some java code using JDBC, but then an SQL syntax error is returned.
Is there a way to emit these commands from JDBC?
Actually, you have to call the admin proc in SYSPROC to do the job. The documentation is not that clear but I've been able to delete an index by using:
CALL SYSPROC.SYSTS_DROP('DB2ADMIN','TESTS_FTS_FT','en_US',?)
Related
I am touching an old report using Oracle Report Builder 10.1.2.3.0. I believe I am having trouble with some function within the report, but the error is very generic and does not point to a specific object.
MSG-00002: Init failed
REP-1416: '': User exit 'G_Catgeory'. .
REP-0069: Internal error
REP-57054: In-process job terminated:Terminated with error:
REP-1416: MSG-00002: Init failed
REP-1416: '': User exit 'G_Catgeory'. .
Is there a way to write to the concurrent request log file from an RDF (Report Builder data definition)?
I have tried using DBMS_OUTPUT commands within a RDF function but the object will not compile:
'DBMS_OUTPUT is not a procedure or is undefined.'
Any tips on how to debug these old school reports is appreciated.
It appears that the author used the SRW built-in package and its USER_EXIT procedure, i.e.
srw.user_exit('G_Catgeory')
(by the way, looks like category was misspelled. Maybe it should have been G_Category).
How to find it? Save the report as a JSP file. Then open it in any text editor (such as Notepad) and search for the above terms. Once you find where it is, you should be able to locate & fix it in Reports Builder.
As of the message you'd want to print: use the SRW package (again), but this time the MESSAGE procedure, e.g.
srw.message(1, 'This is a message');
For more info have a look at Reports Online Help system.
I have a issue. I build myTalendJob and I am running myShell succesfully by adding a contextVariable. The command I use is:
./mainJob_run.sh --context_param myVar="/myDirectory/file.txt"
Is it possible to simply run ./mainJob_run.sh and passing dynamically --context_param myVar="/myDirectory/file.txt" avoiding to rewrite it anytime?
Thank you in advance!
I am not sure I understand your question but this is my attempt to answer.
Either:
When exporting your job, override the context "myVar" by this given value
Write caller script to call mainJob_run.sh appending this additional parameter. I prefer this one as it gives more flexibility
Implicit contexts load
You can read your context params from a file.
With this, you don't need to pass the context params through the shell command, but instead it reads the context params from a file when the job is executing.Ideally, you should put this in your tPreJob.
After reading the values, you can also pass the context params through a tJavaRow for further processing. This way you can format your context params, or generate new context params based on the input values.
TalendByExample has provided a great guide on how to build a reusable context loading job which you can call from any of your jobs.
https://www.talendbyexample.com/talend-reusable-context-load-job.html
I am using Toad Data Point V4.0 to connect to Hive. I try to set below properties using Toad.
set hive.input.format=org.apache.hadoop.hive.ql.io.BucketizedHiveInputFormat;
set hive.optimize.bucketmapjoin=true;
set hive.optimize.bucketmapjoin.sortedmerge=true;
While I can set these properties via Beeline, TOAD throws below error when running above set commands.
[Hortonworks][Hardy] (80) Syntax or semantic analysis error thrown in server while executing query. Error message from server: Error while processing statement: Cannot modify input.format at runtime. It is not in list of params that are allowed to be modified at runtime
Wondering if I have to set these properties somewhere in connection setup or not. Appreciate your input.
We've found a very similar issue with DBVis on Hive.
DBVis is stripping the ‘hive.’ off of commands like “set hive.mapred.mode=strict”. It then checks hive’s list of parameters allowed to be set at runtime for the parameter: “mapred.mode” instead of “hive.mapred.mode”. Since it does not find the parameter, it throws and error.
If we preface the parameter by a second “hive.” (for example, “hive.hive.mapred.mode=strict”) DBVis appears to strips off the first “hive.”. It then finds the stripped version as allowed and sends the stripped version to hive where is executes fine.
NB: This only seems to affect parameters beginning with "hive.".
I'm trying to use CallableStatements to get the value of IDENTITY() in HSQLDB from Java JDBC.
I can prepareCall fine. The issue is with registerOutputParameter. I get "parameter index out of range" no matter what index I pass in.
I've tried SQL snippets like "{? = CALL IDENTITY()}" with no luck.
Any clues? Am I completely off track in how to invoke HSQLDB function routines from JDBC?
Instead of using IDENTITY(), use getGeneratedKeys() to retrieve any keys generated by the (insert) statement.
Note that you do need to use one of the Statement.execute... or Connection.prepare... methods that will enable this feature.
Gah.
http://sourceforge.net/tracker/index.php?func=detail&aid=3530755&group_id=23316&atid=378134
Output parameters for function invocation is not supported. Use executeQuery and grab the ResultSet.
Has anyone seen this error when trying to call an external C function from an Oracle query? I'm using Oracle 10g and get this error every time I try to call one of the two functions in the library. A call to the other function returns fine every time, though the function that works is all self-contained, no calls to any OCI* functions.
Here's the stored procedure that is used to call the failing C code:
CREATE OR REPLACE PROCEDURE index_procedure(text in clob, tokens in out nocopy clob, location_needed in boolean)
as language c
name "c_index_proc"
library lexer_lib
with context
parameters
(
context,
text,
tokens,
location_needed
);
Any help would be appreciated. Everything I've found on this error message says that the action to take is: Contact Oracle customer support.
Edit: I've narrowed it down to the point that I know that there is a segfault deep in libclntsh after I call OCILobTrim (to truncate it down to 0 length) on the tokens clob. Here is the code I've been using to call this procedure.
declare text CLOB; tokens CLOB;
begin
dbms_lob.createtemporary(tokens, TRUE);
dbms_lob.append(tokens, 'token');
dbms_lob.createtemporary(text, TRUE);
dbms_lob.append(text, '<BODY>Test Document</BODY>');
index_procedure(text, tokens, FALSE);
dbms_output.put_line(tokens);
end;
/
Is there something wrong with this setup that might be causing OCILobTrim problems?
It looks like this is one of those errors that essentially means any number of things could have gone wrong with the external procedure.
There is a known bug in 10.2.0.3, no idea if it's relevant:
ORA-28579 occurs when trying to select
data from a pipelined table function
implemented in "C" using the
ODCITable/ANYDATASET interface.
ODCITableDescribe works fine but
ODCITableFetch generates an ORA-28579
error.
I would suggest:
Look in the database server
trace directories, and the directory
where the external proc is located,
for any log or trace files generated
when the error occurs.
Instrument your external proc in
some way so that you can try to
trace its execution yourself.
Contact Oracle support
Well, an upgrade to 10.2.0.4 (was using 10.2.0.1) at least gave me an understandable error instead of a fairly useless core file and the ORA-28579.
It turns out that the code I was debugging was assuming that calling OCILobRead would return all of the data in one pass. This is the case for any client using a fixed width character set.
For clients using a variable width character set, this isn't the case, OCILobRead was actually reading part of the data and returning OCI_NEED_DATA and future calls to OCILobTrim and OCILobWrite were failing because of the still pending call to OCILobRead. The solution was to loop OCILobRead calls until OCI_NEED_DATA was no longer returned and we had all of the needed data in our buffer.
A call to OCIBreak also would have allowed the OCILobTrim and OCILobWrite functions to continue, though we wouldn't have had all of the needed input data.