I'm writing tests for my Laravel application and using MySQL for my development database but using SQLite in memory for my testing database with PHPUnit.
I'm trying to write a query that will get the current datetime for my development query and for the testing of my query.
Right now I have the following.
->select(DB::raw('DATEDIFF(IFNULL(DATE(champions.lost_on), now()), DATE(champions.won_on)) as length))
It says that I can't use now() with SQLite. Does anyone have a suggestion?
According to this answer you will need something like:
SELECT julianday(champions.won_on) - coalesce(julianday(champions.lost_on), julianday('now'))
You might want to cast that to integer.
Related
I wonder if there is some type of common method that would help me write query with date/time field in it. For example: I am developing a very small project utilizing MySQL database. However, my client is considering switching to his existing SQL server.
Example (datetime column):
SELECT DATE_FORMAT(contract_date, '%d.%m.%Y') FROM `employees`
Question: Can query below become usable in SQL in case I replace database driver (currently) mysqli to sqlsrv?
I understand I can use some type of config variable for date format... Would it be the best way? Is there something that Codeigniter 3 has in place?
feel free to use your own query sample
I have similar databases, they come from the same CMS but they use different databases: some are originally SQL Server, and another one is MySQL.
I had to migrate the MySQL database to SQL server since I have some scripts ready for SQL Server which a. a don't want to convert, b. are more complicated to convert since some functions I use are not implemented in MySQL.
This query on the database which were originally SQL Server runs without problems:
SELECT Birth_Date+1 FROM TABLENAME
while, when I run it on the same table in the database I migrated from SQL, I get this error:
Operand type clash: date is incompatible with int
Any idea why I get this error and how I can solve it?
I migrated my database with SSMA, SQL Server Migration Assistent, if this can help.
Thank you.
The message is rather clear, you can't use the + operator with a date and an int.
You should use the DATEADD function (in Sql Server)
And DATE_ADD in mysql.
DATE_ADD(Birth_Date, interval 1 DAY) for example.
which is
DATEADD(day, 1, Birth_Date) in Sql Server
The error seems pretty clear. You can't add an integer to a date, although you can add an integer to a datetime. Presumably, the data type of Birth_Date is date in one database and datetime (or something similar) in the other.
Here are two solutions:
SELECT cast(Birth_Date as datetime)+1 FROM TABLENAME;
SELECT dateadd(day, 1, Birth_Date) FROM TABLENAME;
I'm writing a Ruby program using Sequel which is running on the legacy database. There is an issue dealing with different date time formats.
DB has a table which has a column start_date. In Sequel's migration script I set it to DateTime which is a timestamp type in SQLite, however, the legacy data has a different time format:
Some are using an ISO8601, like 2013-09-01T08:28:00+10:00.
Some are using a different one, which I don't know if it has a name, like 2013-09-01 08:28:00.000000+1000.
The problem is, when I run a query against the table and try to filter by start_date, the difference between two date time formats will cause incorrect results.
The query I'm using is:
current = Time.now
MyModel.where { start_date < current }
Sequel will convert it into SQL like this:
SELECT * FROM `my_model` WHERE `start_date` < '2013-09-01 08:28:00.000000'
From my local testing, Sequel looks like it's comparing the date as a string, so 2013-09-01 08:28:00.000000+1000 is less than 2013-09-01T01:28:00+10:00. Because whitespace is less than T this is not what I want.
I could use an iso8601 time like:
current_iso8601 = Time.now.iso8601
MyModel.where { start_date < current_iso8601 }
But it won't solve the problem because the database has two different datetime formats.
My questions are:
Does Ruby/Sequel support querying the database by Date/Time not as a string?
Does it work for different date time formats?
SQLite is just for local testing, in production it will be MySQL. So, the solution should be using general Sequel methods as a adaptor and should not have any database specific methods.
NOTE: the program is not a Rails application.
Thank you very much!
SQLite does not have date/time types (see http://sqlite.org/datatype3.html). It stores datetime values as strings.
The best solution is to use the same database in development/testing that you use in production. If you don't want to do that, you need to convert all the SQLite datetime values so that they all use the same ISO8601 format. That way the comparison operators will work correctly (as they do in MySQL).
I'm trying to convert a postgresql sql-query to mysql. Using a translator.
this is the query in postgres:
comment_date_gmt timestamp without time zone DEFAULT timezone('gmt'::text, now()) NOT NULL,
it's converted to
comment_date_gmt timestamp DEFAULT timezone('gmt',
The none-closed parenthesis is a sign that everything isn't right. I'm trying to figure out what this query should look like. Any suggestions?
The only reliable SQL query dialect converter is the human brain.
Tools can be useful for the basics, like data type renaming, but lots of that sort of thing can be avoided by just writing the queries using standard types in the first place.
You'll have a very hard time converting a MySQL query that uses query variables to a PostgreSQL query, or converting a PostgreSQL (well, SQL-standard) recursive common table expression to something MySQL understands. The two have totally different stored procedure languages, different built-in functions, and all sorts of things. array_agg, unnest, etc ... most of that stuff would require translation to queries using MySQL variables where it's possible to do it at all. Then you've got window functions like row_number, lead, lag, and aggregates used as running windows like sum(blah) OVER (...). A generic converter would need to "understand" the query to actually do the job.
A specific answer for the named problem isn't really possible since you haven't identified the converter tool.
At a guess, if you change the PostgreSQL query to:
comment_date_gmt timestamp without time zone DEFAULT (current_timestamp AT TIME ZONE 'utc') NOT NULL,
which is the standard phrasing understood by PostgreSQL and other compliant databases.
I am working in a project where we are using SQL Server database currently. But recently a decision has been taken that the database will be changed to MySQL.
I am not using any stored procedures, views, triggers, user defined functions, etc. But I think even then some queries written for SQL Server will not be supported by MySQL.
Can anyone help: what are the things that I have to check (and change) so that all the queries will work properly for MySQL also?
Queries that I know without consulting the documentation that will not work:
(recursive) common table expressions
windowing functions
queries using the standard SQL string concatenation ||
UPDATEs with JOIN are different between the two systems
Date arithmetics: date_column + 1 behaves differently in SQL Server
Division by zero will produce an error
SQL Server will reject values that do not fit into a column (instead of silently truncating it, which MySQL does in the default installation)
DDL that will not work and might have an impact on performance and/or data quality
datetime columns where you need precision up to milliseconds
tables with check constraints
indexed views
triggers on views
table functions (select * from my_function(42);)
filtered indexes ("partial index")
function based indexes
There's always the option to take commercial support from MySQL AB for this problem. I'm pretty sure they've done enough MSSQL->MySQL migrations to know alot about that. If a price tag on the migration is not a problem.
Alternatively, you could try to run the MySQL Migration Toolkit over the data and look for meaningful error messages at the stuff it cannot migrate. MySQL Migration Toolkit is part of the MySQL GUI Tools.