I have two PC's both of them with Win2008 R2 set it up exactly the same.
On one PC the sum(FIELD_NAME) returns a decimal number (CORRECTY) on the other
the same sum(FIELD_NAME) returns the same number as STRING !!!
I have set the System_Time_Zone to be the same on both PC (GTB Standard Time) but the problem still exist. I had uninstall and install back again MySQL on the second PC but still no luck.
I had try tzutil (O/S command) and set the time zone to the above desired but still have the same problem.
With show variables like "%time_zone%" the correct pc shows
system_time_zone : GTB Standard Time
time_zone : System
the "wrong" pc shows
system_time_zone : AN EMPTY SPACE
time_zone : System
my final solution is to reinstal Windows again but.... :o((((
any suggestions ?????
I suggest you confirm the version of the MySQL Connector you are using (not clear whether you are using the Connector/ODBC, Connector/Net or Connector/J.
What MySQL returns is interpreted/translated by the Connector. I think the issue is likely a differnce in the connector being used, or the verison of the connector, or possibly just a difference in the configuration of the Connector (for example, the DFLT_BIGINT_BIND_STR parameter in Connector/ODBC.)
(Less likely, the behavior you observe could be due to a difference in the characterset encodings.)
The details for configuration, debugging and tracing are different for each Connector.
http://dev.mysql.com/doc/index-connectors.html
Related
my current timezone is Asia/Karachi and when i retrieve table data from mysql it gives me (actual time - 5 hours)
for eg:
mysql column value: '2021-04-21 01:34:57'
and when i retrieve from laravel DB::table('table_name')->get()->toArray();
it gives following :2021-04-20 20:34:57
and changing my timezone doesn't change anything either.
so is there something else i'm missing ?
btw i created following route for checking my current timezone
$app->get('/timezone', function () {
return date_default_timezone_get();
});
and it gives same what is saved in my env i.e(Asia/Karachi) but this doesn't change the result i get from mysql even if i change it to some other timezone like Asia/Kolkata.
I tried researching on this but didn't get any suitable answer.
i tried alot of things to solve this issue like
adding env variables APP_TIMEZONE="Asia/Karachi" (did not work)
also i tried adding DB_TIMEZONE="+05:00" (this worked in my local but not on stagging)
finally i saw somewhere that someone else had exact same issue resolving this and he did it by adding the hours using carbon which also worked for me
'posted_at' => Carbon::parse($record->posted_at)->addHours(5)->toDateTimeString(),
i know this is not the optimal solution but this was the only solution that worked so i had to go with it.
https://dev.mysql.com/doc/refman/8.0/en/datetime.html
If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions. The current time zone is available as the value of the time_zone system variable.
As far as I know, you have a couple things to consider:
The timezone of your Laravel/Lumen app
This can be found found in config/app.php -> timezone.
The timezone of your MySQL server
You can retrieve this using:
mysql> SELECT ##global.time_zone, ##session.time_zone;
The timezone of the server itself
If the mySQL query above returns SYSTEM, it means it uses the system timezone setting, which for Debian/Ubuntu etc you can check using:
cat /etc/timezone
From my experience, you can most often leave the system/mySQL timezones intact and only set the correct timezone in your Laravel config. I know it caused me a headache the first time I had to figure out how this actually worked.
why do the following queries work on Maria DB (10.1.9)...
SET SESSION wait_timeout = 28000;
SET SESSION wait_timeout = ##wait_timeout;
SELECT GREATEST(28000, ##wait_timeout);
... but that one not?
SET SESSION wait_timeout = GREATEST(28000, ##wait_timeout)
It throws a type error:
#1232 - Incorrect argument type to variable 'wait_timeout`
Allthough this error can be resolved by replacing #wait_timeout with CAST(##wait_timeout AS INT) or CONVERT(##wait_timeout, SIGNED) (the latter works on MySQL as well) to the query I wonder why the second and third query work.
What's going on here? It can't be the GREATEST operation because query 3 works and it can't be a differing variable type because the (implicit) conversion would fail in query 2 (it should have the same type anyhow). The same thing happens with other system variables as well.
By the way: The same query works under MySQL (tried it in a SQLfiddle with MySQL version 5.6) so this is an inconsistency between MariaDB and MySQL.
Any help appreciated!
As some have guessed correctly: it's a bug (now confirmed) that was introduced recently.
For more details have a look at the mariadb issue tracker:
https://jira.mariadb.org/browse/MDEV-9516
Update (2016-03-21)
Regarding the bugtracker the problem seems fixed in 10.1.13.
I've made an application in Java EE that uses Hibernate to communicate with MySQL. It works perfectly on my Windows development machine, but I have problem on debian, where the application is deployed.
When I search for keyword with Polish letters(like ł, ą, ć, ó etc,) the result is ok on Windows, but on server, where I have imported the database it does not work.
Hibernate query looks like this:
#NamedQuery(name = "Keyword.findByKeyword", query = "SELECT k FROM Keyword k WHERE k.keyword = :keyword")
and is called like this:
myEntityManager.createNamedQuery("Keyword.findByKeyword").setParameter("keyword", keyword).getSingleResult();
When I use mysql on debian via SSH and type in SELECT query manually:
SELECT * FROM keywords WHERE keyword = 'ser żółty';
it also works and return single result. Encoding and collations of tables and columns are also ok. In datasource configuration I've added
?UseUnicode=true&characterEncoding=utf8
parameters, but it also did not help. I thought that maybe there is a problem with encoding in data from request send by form, but the problem appears even if the parameter i.e. "ser żółty" is hardcoded in my repository class.
I also use Hibernate Search for indexing and the FullTextEntityManager return correct results with Polish letters.
I assume that there is some problem between Hibernate and MySQL, but I have no more ideas what could I change. Any suggestions?
Server Wildfly9.0.1, MySQL 5.6
Ok the problem was in encoding on the mysql server level. It was set to latin1 by default. To fix this follow this question Change MySQL default character set to UTF-8 in my.cnf? and edit your my.cnf file.
I just updated the JDBC driver for my application from
mysql-connector-java-3.1.12-bin.jar
to
mysql-connector-java-5.1.34-bin.jar.
With the v3.x driver, this kind of a query works:
select concat("<a href>", count(sakila.payment.payment_id), "</a>")
from sakila.payment;
But now with the new v5.x driver, the query only works with a cast().
select cast(concat("<a href>", count(sakila.payment.payment_id), "</a>")
as char(30)) from sakila.payment;
Is there any property in the MySQL database I can change?
I don't want to change hundreds of queries like that.
I suspect that you will have to bite the bullet and update your code. There is a bug report here that seems to match your circumstances and the status of that bug report is "Won't fix". The response from the developers ([4 Apr 2007 17:43] Reggie Burnett) was:
This is something that we can't really fix. Let me explain.
MySQL has several issues when it comes to reporting whether a result if binary or not. This was very bad on MySQL versions prior to 5.0 but it's still a problem even today. The SQL you reported is returned by MySQL as binary when it obviously is not. The connector can't know for sure. With 5.0.5 and 5.0.6, we tried to make a "best guess" but that code caused more problems than it solved, so with 5.0.7 we have rolled it out. Your SQL will return string properly with 5.0.7, but that doesn't mean it's fixed. In fact, it returns string because we are ignoring the binary flag so that means you could generate valid SQL that should return binary and 5.0.7 will return string.
Until the server is fixed, the connector just can't always do the right thing. I hope this has cleared it up somewhat.
When I set useLegacyDatetimeCode=false in my JDBC connection properties, I get this error message:
java.sql.SQLException: The server timezone value 'CET' represents more
than one timezone. You must configure either the server or JDBC driver
(via the serverTimezone configuration property) to use a more specifc
timezone value if you want to utilize timezone support. The timezones
that 'CET' maps to are: Europe/Tirane, Europe/Andorra, Europe/Vienna,
Europe/Minsk, Europe/Brussels, Europe/Sofia, Europe/Prague,
Europe/Copenhagen, Europe/Tallinn, Europe/Berlin, Europe/Gibraltar,
Europe/Athens, Europe/Budapest, Europe/Rome, Europe/Riga,
Europe/Vaduz, Europe/Vilnius, Europe/Luxembourg, Europe/Malta,
Europe/Chisinau, Europe/Tiraspol, Europe/Monaco, Europe/Amsterdam,
Europe/Oslo, Europe/Warsaw, Europe/Lisbon, Europe/Kaliningrad,
Europe/Madrid, Europe/Stockholm, Europe/Zurich, Europe/Kiev,
Europe/Uzhgorod, Europe/Zaporozhye, Europe/Simferopol,
Europe/Belgrade, Africa/Algiers, Africa/Tripoli, Africa/Casablanca,
Africa/Tunis, Africa/Ceuta.
I understand what the message is telling me, but I'm not sure what to do about it. I don't have any way of knowing what time zone the MySQL server is running in (this is software that my customers install, and the servers are not managed by me).
I need to set this property to false to fix MySQL time zone bugs.
You need to pass an additional parameter like this:
db=jdbc:mysql://localhost/db?user=me&pass=secret&useLegacyDatetimeCode=false&serverTimezone=Europe/Vienna