I am attempting to call a DB2 function from PHP using zend_db to connect to DB2, and calling a SQL statement like so:
SELECT colA, colB, colC, mylib.testfunc(colA, colB, colC)
FROM otherlib.tableABC
WHERE colA = ... etc
(Just for reference, this is to call an RPG program that returns a specific value, so it is only returning one value). This works in an ACS Run SQL Scripts window, but when I try on Zend, I'm getting the following error:
Fatal error: Uncaught exception 'Zend_Db_Statement_Db2_Exception' with message 'TESTFUNC in MYLIB type *N not found. SQLCODE=-204'
I have double-checked to make sure my function does actually exist and it's in mylib. Doing a google search came up with nothing really helpful. Why would it be telling me that it doesn't exist? Is there something specific I have to configure when connecting to DB2 through Zend_DB?
In case it's important, I made the function like this:
CREATE OR REPLACE FUNCTION mylib.testfunc(iA DECIMAL(2,0), iB CHAR(4), iC DECIMAL(2,0))
RETURNS CHAR(10)
MODIFIES SQL DATA
LANGUAGE SQL
BEGIN
DECLARE oReturn CHAR(10) DEFAULT ' ';
-- Here I call a procedure I created to call the RPG
-- and format data...
RETURN oReturn;
END
Thanks in advance.
Is the userid (account-name) for connecting to Db2 the same between PHP and 'ACS Run SQL Scripts' ?
If not, verify that the account used for PHP has execute access to the function and whatever stored-procedures or external programs/routines the function invokes.
Additionally, when your SQL function CALLs the stored-procedure consider using a qualified stored-procedure name.
Related
I am using Laravel 4.2 and am calling a Stored procedure from a database on the server. Locally it works fine, but on the server, using the same DB, it gives error. The call is as follows (I just want to make select):
$result = DB::select('CALL sp_special_prices("'.$codClient.'", "'.$codProduct.'", "'.$quantity.'", "'.$grup.'", "'.$FirmCode.'")');
When running a product listing on the server, it works except for two articles, giving the following error:
Caught exception: SQLSTATE[HY000]: General error: 2053 (SQL: CALL sp_special_prices("C000000", "445706049", "1", "146", "75");)
I already checked the php versions, and am using 5.6 on both sites. Could it be some special configuration? Is that the DB is the same, the place to call the SP, is that it is different.
If the procedure doesn't return anything, you need to use DB::statement instead of DB::select. If it does return something, you need to use DB::select
If the procedure has variable behaviour (may or may not return data depending on input), I suggest you change the procedure to return some data for all input combinations
I have created a console command and I need to truncate a table.
Reading the Class reference: http://www.yiiframework.com/doc-2.0/yii-db-command.html#truncateTable()-detail I am not able to understand what files I need to include in order to execute this command.
I am including:
use yii\db\Command;
use yii\db\Connection;
but not sure which one is correct.
And I have tried to execute:
$command = Yii::$app->db->truncateTable('user');
which gives me the following error:
Exception 'yii\base\UnknownMethodException' with message 'Calling unknown method: yii\db\Connection::truncateTable()'
and:
Yii::$connection->createCommand()->truncateTable('user');
which gives me the following error:
PHP Fatal Error 'yii\base\ErrorException' with message 'Access to undeclared static property: Yii::$connection'
I really don't understand what I need to do.
Yii::$app->db->createCommand()->truncateTable('user')->execute();
Using yii2 migrate that default function
yii2 migrate
Step 1. Create a migrate
yii migrate/create truncate_table_xxx
Step2. Edit file xxx_truncate_table_xxx
Some thing like that
class m150101_185401_truncate_table_xxx extends Migration
{
$this->dropTable('xxx')
}
Alternatively one may use:
User::deleteAll();
assuming User is active model class.
This command shows the number of deleted records.
Note, that unlike truncate deleting all records will NOT reset autoincrement counter to 1.
I'm currently developing an application in PHP which uses PDO. I'm writing an import which reads in a CSV file, checks the database for a record, and updates, deletes, etc....
Something which I've noticed is the memory being used by this script seems very high and it seems like it could be to do with the way I'm executing the query. see below for example query which is executed for each line in the CSV:
$qry = "SELECT * FROM company WHERE id = 1";
$sth = $this->prepare($qry);
$sth->execute();
$sth->setFetchMode(PDO::FETCH_INTO, new Company());
$sth->fetch();
for the above memory_get_peak_usage() = 6291456
When using the below:
$qry = "SELECT * FROM company WHERE id = 1";
$sth = $this->prepare($qry);
$sth->execute();
$sth->setFetchMode(PDO::FETCH_CLASS, "Company");
$sth->fetch();
for the above memory_get_peak_usage() = 524288
As you can see the difference is fairly big.
I guess I've 3 questions..
Is there a memory leak when using PDO::FETCH_OBJ in PHP 5.3.5?
Is there any difference between using FETCH_CLASS as opposed to FETCH_OBJ?
Has anyone else experienced the same issue?
Company Class is simple:
class Company {
function __construct(){}
/**classvars**/
public $_tablename = 'company';
public $transient;
public $id;
public $name;
/**endclassvars**/
}
Looking at the PHP changelog, there does appear to be a relevant fix in 5.3.4 where a memory leak was fixed in PDO FETCH_INTO.
From what you've said, I suspect that yes, this is the bug you're seeing. The solution, of course, is to upgrade -- there really is no point in sticking with an old patch release.
Even if this isn't the bug you're seeing, there have been a very large number of PDO fixes in the versions between 5.3.3 and now; I'm sure there's a good chance that at least some of them are relevant to you.
Note: the original answer was given before the OP changed PDO::FETCH_OBJ to PDO::FETCH_INTO
After that update I've tried to reproduce the behaviour using PHP 5.3.10-1ubuntu3.4. There where no significant difference in memory cosumption between both fetch modes. I've tested using a large MySQL table and a large SQLite database.
As #SDC mentioned the bug is known and was fixed after 5.3.5. (At least in 5.3.10 as I've seen).
Conclusion: You have to upgrade your PHP version.
Although the behaviour is interesting and should be investigated you are using PDO::setFetchMode() in a wrong way. When $mode - the first param - is PDO::FETCH_OBJ no second param is expected. If you use a second param the call to setFetchMode() will fail (returnin false) and the default fetch mode FETCH_BOTH will be used.
You can see this error when enabling PDO::ERRMODE_EXCEPTION :
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $db->query('....');
// the following line will trigger an exception
$stmt->setFetchMode(PDO::FETCH_OBJ, new Company());
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: fetch mode doesn't allow any extra arguments'
When you are expecting that result rows should objects of a specific class, then PDO::FETCH_CLASS is the working attempt. PDO::FETCH_OBJ will return objects from type StdClass
FETCH_INTO: Means fetching into an existing Object (that was created with new e.g.)
FETCH_CLASS: Means fetching into an new Object (the constructor is called every row)
Be careful, if the constructor in your Company class has dependencies, they are called for every row. Therefore the constructor should not contain functions or classes that do an DB connect e.g. only simple initializing...
How does your Company class look like?
I have a database that has a few stored procedures in it that I would like to call via CodeIgniter. I have the following code in my Model class:
$sql = "CALL `stored_proc`(1)";
$query = $this->db->query($sql); //This call breaks the DB :(
$this->db->select('status');
$this->db->where('id', $id);
$query = $this->db->get('table');
print($query->num_rows()); //line 1116
When I run this code, I get the following error:
Fatal error: Call to a member function num_rows() on a non-object in C:\server\apache\htdocs\application\models\let_model.php on line 1116
If I remove the query line, the select works properly. Also, if I replace the call to a stored procedure with say a SELECT command, it also works properly.
Is there something obvious I'm missing for why I'm getting this error? If there isn't a good answer, is there a way to work around this problem?
Thanks for your time!
Edit: After delving a little deeper into the problem, it seems that this error will occur if my stored procedure contains a SELECT command. UPDATES seem to work properly. Perhaps this problem has something to do with how CodeIgniter deals with SELECT results?
Since this question appears first on google, i've managed to solve this by using :
$this->db->simple_query($query);
Instead of the regular query function.
The problem was that the SELECTs in the stored procedure were causing problems in CodeIgniter. By making sure that all of the SELECTs were directed (i.e. with the INTO clause), the stored procedure was able to run successfully.
For example,
-- This causes an error in CodeIgniter when inside a stored procedure.
SELECT GET_LOCK('lock1',0);
-- This does not.
DECLARE _lock_result INT;
SELECT GET_LOCK('lock1',0) INTO _lock_result;
I am still unaware of the underlying causes of why this causes an error, but this solution will suffice for my current work.
use only
$query->num_rows instead of $query->num_rows()
$sql='INSERT INTO complaints(complaint_id) values(default)';
$db->query($sql,array());
//get newly added complaint_id
$complaint_id=$db->lastInsertId();
I used above code to get last insert ID from complaints table. But it gives an error like
Fatal error: Call to undefined method EMMACore\Utils\DBConnection::lastInsertId() in /h... Can anybody tell me what is wrong in my application.Thanks.
In most case, the PDO instance is a property of EMMACore\Utils\DBConnection, so check the source code and find it out.
Something like: $db->getDbh()->lastInsertId(); where getDbh (or something like that) returns the PDO instance.
Edit: After seeing your result of var_dump(), that is for sure.
class db extends PDO
you can refer to this link PHP PDO Wrapper Class for example.