Delphi 7 how to load data from an ADOQuery to a DBChart at runtime - runtime

Im having the following problem with Delphi 7.
I try to use a DBchart to represent some data with a line diagram from a database.
I want the data to be loaded from an ADOQuery that gets activated at runtime thought. I can do it without problem with a query that has a static SQL value, but i find problems at setting the datasource at runtime.
I try to use
dbchart1.series[1].datasource:=ADOQuery3;
After i have created series1, but i get a "list index out of bounds" error.
Am i using the wrong command? I tried several others but failed.
Anyone can give some help with this?

Solved it with the following (after creating series1 at the DBGrid)
with series1 do
begin
datasource:=ADOquery;
xlabelssource:='field1';
YValues.Valuesource:='field2';
checkdatasource;
end;

Related

Getting ORA-01008 error when trying to execute a function via OCI

We are trying to execute an oracle function that requires parameters and we are getting the error ORA-01008- Not all variables are bound. We are pretty sure the problem is in how we are binding the variable that is supposed to received the result of the function. First we tried the following (a method without parameters):
$tSql:="select staging.FUNC_ORAOCI_TEST() from dual"
$iStatus:=OCIHandleAlloc (envhp;$stmthp;OCI_HTYPE_STMT)
$iStatus:=OCIHandleAlloc (envhp;$errhp;OCI_HTYPE_ERROR)
$iStatus:=OCIStmtPrepare ($stmthp;$errhp;$tSql;OCI_DEFAULT)
$iStatus:=OCIDefineByPos ($stmthp;$bindpp;$errhp;1;->atResults;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;OCI_DEFAULT)
$iStatus:=OCIStmtExecute (svchp;$stmthp;$errhp;1;0;0;0;OCI_DEFAULT)
And it worked perfectly...
Where we got stuck was when trying to pass parameters to the function (which we had modified on purpose to now accept parameters)
We thought it was because we now had to make the binding by name, but it just did not work. We have tried running a PL/SQL block and still we get the error. Here are our failed attempts:
Using a SQL Statement:
$tSql:="select staging.FUNC_ORAOCI_TEST(:tParamText,:iParamNum) from dual"
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":tParamText";- >tParamText;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":iParamNum";->iParamNum;SQLT_INT;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIDefineByPos ($stmthp;$bindpp;$errhp;1;->atResults;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;OCI_DEFAULT)
$iStatus:=OCIStmtExecute (svchp;$stmthp;$errhp;1;0;0;0;OCI_DEFAULT)
Using a PL/SQL Anonymous Block:
$tSql:="DECLARE vResult VARCHAR2:=''; BEGIN vResult := FUNC_ORAOCI_TEST(:tParamText,:iParamNum); End;"
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":tParamText";->tParamText;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":iParamNum";->iParamNum;SQLT_INT;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":vResult";->tResult;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_OUT)
$iStatus:=OCIStmtExecute (svchp;$stmthp;$errhp;1;0;0;0;OCI_DEFAULT)
We have looked at similar questions but no one was trying to use the OCI interface to execute the function the way we are doing it.
We are coding in 4D so ignore the weird syntax. We just need guidance as to how build the statement and what would be the proper OCI command to reach a successful binding.
We partially resolved this issue.
We have got it to work only for SQL statements not for PL/SQL. But we got rid of the ORA-01008 error.
The code in case 1 referenced above works as is. We did some clean up of comments and lines that were added for debugging, but they might have altered the sqlstmt somehow, thus affecting the binds.
The code in case 2 now gives an error "Invalid SQL Statement" which we will open a new inquiry for in separate thread.
One very useful information that we found to help us resolve the initial inquiry can be found here:
https://docs.oracle.com/database/121/LNOCI/oci05bnd.htm#LNOCI16368

Error "OUT paramater used in non-stored procedure call : ORACLE_REF_CURSOR class java.sql.ResultSet" while running a Jasper Report

I am getting the following error when running the report. Any idea why? This is a report which was working earlier but not sure what changed and it stopped working.
Error filling print... OUT paramater used in non-stored procedure call : ORACLE_REF_CURSOR class java.sql.ResultSet
Setting up the file resolver... 
net.sf.jasperreports.engine.JRException: OUT paramater used in non-stored procedure call : ORACLE_REF_CURSOR class java.sql.ResultSet 
    at com.jaspersoft.jrx.query.PlSqlQueryExecuter.createStatement(PlSqlQueryExecuter.java:369) 
    at com.jaspersoft.jrx.query.PlSqlQueryExecuter.createDatasource(PlSqlQueryExecuter.java:113) 
    at net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(JRFillDataset.java:1086) 
    at net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(JRFillDataset.java:667) 
    at net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(JRBaseFiller.java:1258) 
    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:877) 
    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:822) 
    at net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:61) 
    at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:446) 
    at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:276) 
    at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:745) 
    at com.jaspersoft.ireport.designer.compiler.IReportCompiler.run(IReportCompiler.java:891) 
    at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572) 
    at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997) 
Print not filled. Try to use an EmptyDataSource...
I resolved the problem by removing the ORACLE_REF_CURSOR argument from procedure call within the Jasper report.
The procedure call was like {call procedure1($P{param1}, $P{ORACLE_REF_CURSOR})} when it was throwing the above error. After removing the ORACLE_REF_CURSOR argument from the call, its working now. Here is how the procedure call looks like{call procedure1($P{param1})} in the report.
Funny thing is that the report was working before with the ORACLE_REF_CURSOR in the argument of the procedure, but suddenly started throwing the above error.
If somebody has more explanation on this problem then do please update the answer.

ResultSet.getString() on VARCHAR2 column returns empty string

Disclaimer: I don't actually know anything about nether Oracle nor Java. The issue is in a project that some other developer completed at some point in time and then left the company. Now I have to setup webserver, database and get it all up and running.
the code is approx this:
OracleDataSource ods = new OracleDataSource();
ods.setURL("jdbc:oracle:thin:<user>/<password>#localhost:1521:xe");
OracleConnection ocon = (OracleConnection)ods.getConnection();
OracleStatement stmt = (OracleStatement)ocon.createStatement();
OracleResultSet rs = (OracleResultSet)stmt.executeQuery("SELECT POLLID, QUESTION, ISMULTISELECT FROM POLL WHERE POLLID = " + pollID);
if (!rs.next()) {
System.out.println("No rows found.");
return false;
}
this._PollID = rs.getInt("POLLID");
this._Question = rs.getString("QUESTION");
this._IsMultiSelect = rs.getBoolean("ISMULTISELECT");
The POLLID and ISMULTISELECT columns return correct values as expected. The QUESTION seem to always return empty string. The value in the DB is obviously not empty.
The rs.getAsciiStream("QUESTION").available() also returns zero.
Am I missing something completely obvious here?
EDIT:
sqlplus returns varchar2 value just fine
connecting via odbc (as opposed to thin) also makes things work
so no Exceptions, you are not using reserved words...maybe try to use other driver, or select into other table and experiment start with empty QUESTION column, then add some value and debug.
Thanks to everyone who replied. At this point it seems issue is between thin driver and XE version of Oracle. Unfortunately we don't have full version kickin' around (we are primarily ASP.NET/MS SQL developers), so we'll have to stick with ODBC driver for now and hope issue will magically resolve itself when we push it to live environment (hosted by third party). Very crappy assumption to make, but at this point I see no other options....
I had the same exact issue and found that the root of the problem comes from the orai18n.jar. once i removed this from my classpath, the issue went away.
I have the same problem. I do not have access to the driver that is used because the connection is taken from a Weblogic server using JNDI. I cannot remove any .jar from the server neither.
The workaround I found :
String value = new String(resultset.getBytes());
Make sure you use the right encoding if required :
String value = new String(resultset.getBytes(), [CHARSET])
I had this same issue with eclise GCJ ( Stock centos6 ) and mysql-connector with the same concatenated queries. The problem was solved with reverting back to openJDK.
I had the same issue. "getInt()" would return correct value from Oracle 9i DB, but using "getString()" would result into empty string, no matter how many times i ran, within eclipse or outside on seperate Tomcat or other servers.
After going through a lot of various threads, and quite a few trials, I came to the conclusion that the issue is with the version of ojdbc6.jar that I was using. Earlier, I was using ojdbc6.jar with Oracle version 12.1.0.1., which is not so good for connecting to OLD Oracle 9i DB. After realising, I switched on to ojdbc6.jar from Oracle 11.2.0.3 and it worked like a charm.
Hope it helps. cheers!

Trouble compiling or dropping an Oracle package

I was trying to compile a PL/SQL package and I got the following error:
ORA-04043: object SYS_PLSQL_77721_489_1 does not exist
After this, I can no longer recompile or drop the package.
Do you have any suggestions?
Try to do this:
DROP TYPE SYS_PLSQL_77721_489_1;
DROP TYPE SYS_PLSQL_77721_DUMMY_1;
DROP PACKAGE BODY xxxx;
DROP PACKAGE xxx;
I've had exactly the same problem and works. Sorry #Vicent but the link you provide does not solve the problem.
if you have access to support, this looks like bug #3744836. A similar bug is described here, related to pipelined functions and synonyms.
One confirmed cause of this problem is the use of pipelined functions with PL/SQL types. It is a bug, and so ought to fixed in more recent or fully patched versions of Oracle. A workaround would be to use SQL types instead (i.e. create type whatever as object ... ).
If this does not apply in your situation please edit your question to include more details.
Try to create the types as mentioned in the error message to resolve error while dropping or compiling packages.
Error :ORA-04043: object SYS_PLSQL_ B1A0D561_1132_1 does not exist
Resolution : CREATE TYPE SYS_PLSQL_B1A0D561_1132_1;
After that one more error came which reads
Error :ORA-04043: object SYS_PLSQL_B1A0D561_1242_1 does not exist
Resolution :CREATE TYPE SYS_PLSQL_B1A0D561_1242_1;
and issues resolved.
create or replace type SYS_PLSQL_77721_489_1 as object
for all erros when you drop
try drop again and again and create type for all erros...

ORA-28579: network error during callback from external procedure agent

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.

Resources