I'm trying to setup mysql query profiling as highlighted in http://dev.mysql.com/doc/refman/5.1/en/log-destinations.html
In
/etc/my.cnf
I added:
general_log=1
log_output=FILE
log=/tmp/mysql.log
i did
/etc/init.d/mysqld restart
Stopping MySQL: [ OK ]
Starting MySQL: [ OK ]
My mysql version is:
Server version: 5.0.77 Source distribution
But it did not work! No /tmp/mysql.log
The problem you have is that log_output was introduced in 5.1.
Take a look: http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_log_output
Version Introduced 5.1.6
Also, in the article you pointed it says:
SET GLOBAL log_output='TABLE'; SET GLOBAL general_log='ON';
which has the same effect (note that this is only possible in 5.1)
Another way of analysing this data would be to enable general query logging (just logging to file by adding general_log=1 to you my.cnf) and then to analyse the general query log with mk-query-digest
Related
I am trying to connect php with interbase. It seems php only works with firebird, instead of interbase. I already have a database , that is created in interbase, I just need connectivity with interbase, not firebird. When I am trying to connect it with interbase, it says .. invalid database. where as connection with firebird database is working fine. Using php 5.6, windows server, 64 bit architechture
There's a ton of helpful comments at the ibase_connect function page over at php.net, are you sure that you're following through and checking version numbers? It appears that you may need to perform a manual fix and set the dialect version of the connection, as follows:
ibase_connect ('localhost:/usr/db/db.gdb', 'SYSDBA', 'masterkey', 'ISO8859_1', '100', '1' ) ;
The last 1 as a parameter resets the dialect mode between the ibase_connect() and Interbase. You also should check and see if the version of PHP you're running is compatible with the version of Interbase you're running.
I am currently getting this error in vtiger installation wizard (step 4).
MySQL Server should be configured with:
sql_mode = ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
I am using shared PHP 7.2 MySQL 5.7 hosting and adminer says that sql_mode is set to
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Here comes the question
Is this behaviour really related to sql_mode setting? Do I have to contact my hosting provider or there is there an override?
Connecting to a new mariadb 10 database solved the problem.
Changing MySQL version to <5.7 as stated in comments should therefore work as well.
For Ubuntu - Run command:
sudo nano /etc/mysql/my.cnf
Add the following part to the bottom:
[mysqld]
sql_mode=ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Run command to restart MySQL Service:
sudo service mysql restart
You will also need to change Database Collation to utf8_general_ci in phpmyadmin.
Done !
I think you should pay attention to the port Mysql is using, if you are using Wampserver, By default the new versions install MariaDB first, and MySQL second so MariaDB get the port 3306 and Mysql get the an other one (most of the time 3307).
Vtiger will always try to connect to a database to the port 3306 (unless you change it in the code). So you can change the sql-mode in "/bin/mysqlx.x.x/my.cfg" as you want, and see it changed in the MySQL console, but Vtiger won't be trying to connect to it, but to 3306.
I spent way more time on this issue than it deserved, mostly because I felt that changing the "sql-mode" in the .cfg file to change an "sql_mode" variable was weird and was the issues, idk why MySQL made it like that but that's not user friendly at all.
I'm having some issues loading some data into MySQL on Linux. I'm using LOAD DATA LOCAL INFILE. I can do it just fine on Mac OS X, specifically through the MySQL command line and a php script with a SQL query.
The issue arises when I'm on linux, it seems like LOAD DATA LOCAL is disabled per the MySQL documentation for security issues. To get around this problem, they give some possible workarounds such as using --local-infile[=1] on starting MySQL, but what am I suppose to do if I'm using PHP?
Specifically, in the command line, I get the error:
ERROR 1148 (42000): The used command is not allowed with this MySQL version
I'm also using version:
mysql Ver 14.14 Distrib 5.5.41, for debian-linux-gnu (x86_64) using readline 6.3
Any help would be greatly appreciated.
You can set it from an sql statement, assuming you have the correct permissions to change global variables;
SET GLOBAL local_infile = 'ON';
Check to see if the changes have taken effect;
SHOW GLOBAL VARIABLES LIKE 'local_infile';
I'm trying to use the LOAD DATA LOCAL INFILE command in MySQL, but I keep getting an error in PHP/Joomla stating: The used command is not allowed with this MySQL version
I've spent quite a while Googling around, but the only suggestions I've seen involve adding local-infile = 1 to my my.cnf file (which I've already done, in [client], [mysql], and [mysqld]).
Additionally, if I connect from my Apache server to the MySQL server from the command line (so not using PHP), I can run LOAD DATA LOCAL without issue (so it can't be a permissions thing).
I've also checked php.ini, and sure enough, mysqli.allow_local_infile is set to 'On'.
Am I missing something here?
Do you have to do something special in Joomla to make this work correctly?
I just answered a similar question here, maybe it can help:
After going from MySQL 5.0 to 5.5 I found out that I suddenly have to enable LOCAL INFILE specifically when creating the connection in PHP.
Using mysql:
mysql_connect(server,user,code,false,128); // 128 enables LOCAL INFILE
mysql_select_db(database);
Using mysqli:
$conn = mysqli_init();
mysqli_options($conn, MYSQLI_OPT_LOCAL_INFILE, true);
mysqli_real_connect($conn,server,user,code,database);
I ran into the same problem, in my case it was the Joomla user lacking privileges that root has; giving the full privileges to the J user solved it, but then my component is for distribution so I changed to using standard .sql file and parsing / creating them manually. Hope this helps.
The database management system Sybase ASE supports multiple result sets, however the implementation of Sybase in PHP doesn't. There is a bug reported on this issue and there is also a patch supplied in that report (https://bugs.php.net/bug.php?id=48675). The patch is for version 5.2.9 and I've tried to add it to version 5.3.10. The source builds without warnings or errors, and testing the new function 'sybase_next_result()' does not yield a fatal error "Call to undefined function". This would suggest that the function is implemented, but not working as expected.
Configuration is:
configure --disable-isapi --enable-debug-pack --without-mssql --without-pdo-mssql --without-pi3web --with-mcrypt=static --disable-static-analyze --enable-cli --with-sybase-ct=%SYBASE%\%SYBASE_OCS%
There is a notice on 'sybase_query()' when there are multiple result sets saying "Sybase: Unexpected results, cancelling current in...". The first result set is retrieved. And this notice is returned even without the patch.
The number of stored procedures in the database that return multiple result sets is vast, and a 'sybase_next_result()' would be the best solution. In short, I looking for an equivalent to 'mssql_next_result()' (http://se2.php.net/manual/en/function.mssql-execute.php) for Sybase in PHP 5.3.10.
Worth noting is that the other parts of the Sybase implementation is in place and seems work as expected.
My testing environment is a WAMP server (Windows 7, Apache 2.21, MySQL 5.5.20, PHP 5.3.10) and Sybase ASE is version 15.7.0.
Is there anyone out there that has "solved" this?
With regards
//Jonas
Update:
A colleague gave me the instructions to use 'OutputDebugString()' (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx) and catch that with DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647).
From this I can say that 'sybase_next_result()' is called but the block
if (sybase_ptr->active_result_index) {
...
}
is not run. This is probably correct (as I see it).
The row
retcode = ct_results(sybase_ptr->cmd, &restype);
is always setting 'retcode' to 'CS_FAIL'. This is perhaps because the earlier
ZEND_FETCH_RESOURCE2(sybase_ptr, sybase_link *, sybase_link_index, id, "Sybase-Link", le_link, le_plink);
sets 'sybase_ptr' in sutch fashion that 'retcode' becomes 'CS_FAIL'.