I'm in the process of moving a PHP application from an Ubuntu server to an AWS openSUSE instance.
The application does not work on the openSUSE box. The API fails for any call that has $mysqli->insert_id. Calls using $mysqli do work.
From reading around I have noted that this usually fails because of auto_increment not being implemented on the Database column. I migrated the MySQL database across from the Ubuntu hosted app. The table schema seems to be the same.
I have also looked at the server configuration files php.ini etc. and the MYSQLi extensions seem to be configured correctly.
It is for this reason I think it is a PHP related problem. Any help would be greatly appreciated.
EDIT : To provide more information as requested.
The general structure of each API call that fails is.
The iOS sends a POST to the API
The API (built in PHP) inserts the information into a Table which has a Primary Key that auto-increments.
The API then uses $case_id = $mysqli->insert_id;, obtain the value of this primary key.
This value is returned to the iOS app.
Important - $case_id is being returned as 0.
To troubleshoot an issue like this I would start by isolating where the problem is occurring. Is the schema wrong? If you log into the MySQL server using the MySQL shell and you attempt to manually insert a record, with a NULL for the auto-incremented (primary key?) column does the new record appear properly? If you query using the same underlying SQL statement that's being generated and passed to the server from your PHP/mysqli component does it return the proper row(s)?
If it works using the MySQL shell on the DB server then what if you try the same from the API server? Is it a permissions/ACL or networking issue? If the it works from the MySQL shell on both the DB server and the API (web?) server then does it work from your PHP code? Perhaps you can refactor your PHP to allow you to run tests/diagnostics from the command line (rather than attempting to initiate a transaction through the additional web/UI layers). (This is generally a good idea when writing your web applications anyway). Perhaps you can separate the web/form/ReST handling (view) from the code which passes data back into the DB (the model). Thus you isolate the controller code from the rest and can re-use it for diagnostics and for monitoring.
If you can't get it working even from the DB server's only MySQL shell prompt then you probably have a problem in the schema. Go back to the working DB server and perform a schema dump as described here: http://forums.mysql.com/read.php?35,128003,128105
Then restore that. It should then be a completely empty database with your working schema intact. If that doesn't work then it suggests you have some issues even lower (MySQL version and modules perhaps, missing some storage backends?)
Related
Good day,
I am using wampserver, and I would like to get data from a remote IBM database (AS400) using db2_connect. I've tried searching on some ways but I couldn't get the idea of doing it. I have successfully included ibm_db2.dll extension on my php. However, I don't know what to do next.
As you seem to be using "DB2 Connect" (and not a separate DB2 client) product you can either configure DB2-Connect with a node/alias/dsn and then mention that alias with the db2_connect() action, or use PDO_IBM longer connection string with all the details as mentioned here.
You need to know the tcpip-address (or hostname) of the i-Series DB2-server, and the Port-number it listens on.
Check this technote for the actions required to make a node/alias (I believe the same general configuration pattern applies to DB2-connect as Data server client).
The advantage of configuring like this is that you can verify the database-connect in your workstation command line shell , before making it work in PHP/pdo.
I have a website running with php and mysql on Centos(Amazon instance). The newly brought ERP(to be integrated with existing system) uses Oracle as db(located on a separate Windows server). The orders from the website are inserted into the Master Mysql database and which are replicated into the Slave Mysql database. These orders need to be pushed to the Oracle Db. I have arrived on 4 methods to do this.
Use mysql UDF for http communication that would send the rows on a Insert Trigger on the slave to the Oracle webservices on Oracle server
Use cron jobs(with a low interval may be 5 mins,polling) with Php script that would get the new orders from mysql and send to the Oracle db via Oracle services/Php services on Oracle hosted server.
Use sys_exec() udf to invoke php script to insert into Oracle db
Use memcached with MySql and let Php poll the memcached to retrieve data and send it to Oracle server, but unsure whether we could migrate existing Mysql version to new version Mysql 5.6
I already have the UDF's in place and tested them, they are good to go. but still in dilemma regarding data integrity and reliability in case of using UDF's with triggers.
Is there a better method for doing this. Or else which method shall I follow to do the same.
I am aware of the security threats of UDF's, you can't restrict it to any user
One more thing I am not allowed to introduce new changes to the existing website php code for the operation.
SymmetricDS replicates parts of or entire database schemas across different vendor products. It works by installing triggers, but it replicates on a transaction basis ensuring that transactions gets replayed onn target database (s) in the right order.
I've opened a bug report against MySQL http://bugs.mysql.com/bug.php?id=70793&thanks=4. There is a code example here that demonstrates this on this bug. There is also a workaround that I found that is included in the bug report. This workaround works for PHP and console
I'm running into a bizarre issue with a Stored Procedure and PHP PDO.
I am not allowed to post the body of the stored procedure, but I can provide the following information.
It works correctly on a read only replica when accessed from console with the same user that PHP PDO shares -- Edit: My initial report here is partially incorrect, the stored procedure will work if the temp table exists and will fail if the temp table doesn't exist in both console and pdo environments. See the linked bug report to MySQL for details.
I have verified that I am using the same user in both places.
The only write activity it performs is inside a temp table
It does utilize a cursor
The master and replica are both running MySQL 5.5.27
The MySQL servers are managed on AWS RDS; I have a single parameter group with a standard configuration.
My issue is that I cannot call this stored procedure from PHP PDO, I get this error
SQLSTATE[HY000]: General error: 1290 The MySQL server is running with the --read-only option so it cannot execute this statement
This makes absolutely no sense because I can call this on the read only replica as long as I'm not doing it from PHP.
Can anyone shed any light on what might be going on here?
Edit More bizarre information
I can get a console session to fail, but I can also make it succeed. It depends on if the temporary table that the stored proc uses has already been created. So let me explain my working and failing use cases
Fail
Login to the server on console
Try to call the stored proc
Fail The MySQL server is running with the --read-only option so it cannot execute this statement
Pass
Login to the server on console
Create the temp table
Try to call the stored proc
Success
Even stranger is that I most definitely drop that temp table inside the the stored proc and recreate it if it exists.
I'm reasonably certain at this point we are looking at a MySQL bug
Did you try adding the TEMPORARY keyword to the DROP TABLE command?
The TEMPORARY keyword has the following effects:
The statement drops only TEMPORARY tables.
The statement does not end an ongoing transaction.
No access rights are checked. (A TEMPORARY
table is visible only to the session that created it, so no check is
necessary.)
--read-only is only for non-root or non-replica-user. Thus, ROOT from console can still do anything but not the PHP user.
I have inherited a web-application project (PHP/MySQL) which makes extensive use of stored procedures, and I am unsure how to transfer these to my local machine for development.
Specifically, it is the exporting and importing of these stored procedures that I am facing difficulty with (with the ultimate aim of being able to automate installation of a "base" version of the application database, complete with stored procedures).
I shall state the bits and pieces that I believe I understand:
I can export the information_schema.ROUTINES table, but cannot import it (phpMyAdmin) onto my local server (I believe that information_schema is a system database?)
As I do not have shell/command-line access to the "online" MySQL servers, tools such as mysqldump are only of very limited use (to port to my local testing machine, but not vice versa)
The command SHOW CREATE PROCEDURE procedure_name; is supposed to output SQL that can be used to create the procedure, but I can't seem to get this functioning correctly (ERROR 1305 (42000): PROCEDURE delAddress does not exist)
Assuming that the the above works, the next step is to have it be looped to export all stored procedures (..and then be run via phpMyAdmin elsewhere, to import it)
Please correct anything that is incorrect, and provide guidance on how to automate porting between database servers.
Many thanks
Turns out the solution was ridiculously simple.
On the export page, there is an Add CREATE PROCEDURE / FUNCTION / EVENT statement option.
By checking this box, it also exports the SQL necessary to import procedures at a later date/on another server.
Use MySQL Workbench's migration feature. The whole thing is free and it does an amazing job.
I have just installed and configured Apache, MySQL, PHP and phpMyAdmin on my Macbook in order to have a local development environment. But after I moved one of my projects over to the local server I get a weird MySQL error from one of my calls to mysql_query():
Access denied for user
'_securityagent'#'localhost' (using
password: NO)
First of all, the query I'm sending to MySQL is all valid, and I've even testet it through phpMyAdmin with perfect result. Secondly, the error message only happens here while I have at least 4 other mysql connections and queries per page. This call to mysql_query() happens at the end of a really long function that handles data for newly created or modified articles. This basically what it does:
Collect all the data from article form (title, content, dates, etc..)
Validate collected data
Connect to database
Dynamically build SQL query based on validated article data
Send query to database before closing the connection
Pretty basic, I know. I did not recognize the username "_securityagent" so after a quick search I came across this from an article at Apple's Developer Connection talking about some random bug:
Mac OS X's security infrastructure gets around this problem by running its GUI
code as a special user, "_securityagent".
So as suggested by Frank in the comments I put a var_dump() on all variables used in the mysql_connect() call, and every time it returns the correct values (where username is not "_securityagent" of course). Thus I'm wondering if anyone has any idea why 'securityagent' is trying to connect to my database - and how I can keep this error from occurring when I call mysql_query().
If username is not specified explicitly, MySQL tries to guess it by using name of current system user.
You don't have to accept that, you just need to specify desired username explicitly.
How – that depends how you're connecting. In case of phpMyAdmin it's config.inc.php, add line like:
$cfg['Servers'][0]['user'] = 'Eirik';
(see manual)
Did you set up your local AMP server using a pre-made package, or did you install MySQL, PHP, etc. through the respective OS-specific download packages? Setting up Apache, MySQL, and PHP4/5 can be a real PITA.
If you're having problems with your setup I'd recommend MAMP. It's a nifty all-in-one package that really does the trick. You can still access all the config files you want, and everything is contained in the MAMP folder instead of spread all over the system. If Apple upgrades the pre-installed version of Apache/PHP, your machine-specific config wouldn't be overridden as it would in the case of using pre-installed Apache/PHP.