SQLite is not able to save DateTimeOffSet value - sqlite

In our app the same update is executed in a SQL Server and a SQLite database.
The issue is that SQL Server works as expected however SQLite somehow is getting always 1/1/0001.
This is the update command:
UPDATE ReviewSow
SET
SowingDate = '7/1/2016 12:00:00 AM -03:00'
WHERE
ReviewSowId = 3366;
Any idea why this could be happening?

The solution was rather odd. When converting the date to ticks and passing as a string it works perfectly! Strange but this is how SQLite works.
Example:
UPDATE ReviewSow SET SowingDate = '636263784001230000' WHERE ReviewSowId = 3366;
to convert DateTime to ticks:
((DateTimeOffset)value).Ticks.ToString()

Related

SQLite -> SQLite date formatting issues

I am working on migrating my old application data to a new application database. The old SQLite database has a DateTime column called DateOpened. When I look at the old data, I see this value: 2010-09-16 12:00:00
When I query it in my new (UWP) application, the query returns 1/1/0001 12:00:00 AM, which I assume is because that is DateTime.MinValue.
The result in the new database, is a DateOpened value of -62135510400. Is this storing the value in ticks or something like that? Both SQLite databases have that column as a DateTime field, so I'm not really sure why they are being stored differently.
I updated a different row with the value 1/1/2007 from a DatePicker and it is stored in the new database as 1167694105.602.
I don't necessarily mind that the new database stores the dates this way, but I am trying to figure out a way to get them to copy over properly. I tried manually setting the values in the new database, but with a normal date format (i.e. 1/1/2007), the application crashes when trying to read from the database.
Can someone tell me what I'm missing here? It's probably something simple, but I'm stumped.
EDIT
I was able to get it to read the value correctly from the old database by specifying storeDateTimeAsTicks = false. The default value apparently is true, so my new database is storing as ticks, but when trying to read as ticks from string format, it wasn't working, so it would return DateTime.MinValue.
I was able to get it to read the value correctly from the old database by specifying storeDateTimeAsTicks = false. The default value apparently is true, so my new database is storing as ticks, but when trying to read as ticks from string format, it wasn't working, so it would return DateTime.MinValue.

How to get current date time format in SQlite?

I am using sqlite for local database in mobile and in my database. i want to know that
How to get current date format in SQLITE? I want to get date in the next format: MM/dd/yyyy
To get the current date you can use:
SELECT date('now');
Note: This is NOT a server date, it's the same time you get if you query the date and time directly from your application because SQLITE runs in-process.
It's mostly useful for putting a current time into a table or for some simple calculations if your language's date processing is very poor.
To do the calculations see the SQLITE Documentation
See the docs for formatting too for example:
SELECT strftime('%Y-%m-%d %H:%M:%S', datetime('now'))
According to the SQLite documentation as of this writing (3/30/2020), in the section titled "The DEFAULT clause", it is recommended that a constant value be used instead of a sub-query.
In my experimentation, I also ran into issues with the SQLite CREATE TABLE statement that was generated during model creation by EF Core 3.0 when using SELECT datetime('now'). The SQLite data provider complained of a syntax error when using a SELECT statement within the CREATE table statement. As such, I would recommend using the CURRENT_TIMESTAMP keyword.
for your concrete case, this is what you need:
strftime('%m/%d/%Y',date('now'))

Issue with date when migrating databases between SQL Server 2008 and 2012 [duplicate]

I have the following piece of inline SQL that I run from a C# windows service:
UPDATE table_name SET
status_cd = '2',
sdate = CAST('03/28/2011 18:03:40' AS DATETIME),
bat_id = '33acff9b-e2b4-410e-baaf-417656e3c255',
cnt = 1,
attempt_date = CAST('03/28/2011 18:03:40' AS DATETIME)
WHERE id = '1855'
When I run this against a SQL Server database from within the application, I get the following error:
System.Data.SqlClient.SqlException: The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
The statement has been terminated.
But if I take the piece of SQL and run it from SQL Management Studio, it will run without issue.
Any ideas what may be causing this issue?
Ambiguous date formats are interpreted according to the language of the login. This works
set dateformat mdy
select CAST('03/28/2011 18:03:40' AS DATETIME)
This doesn't
set dateformat dmy
select CAST('03/28/2011 18:03:40' AS DATETIME)
If you use parameterised queries with the correct datatype you avoid these issues. You can also use the unambiguous "unseparated" format yyyyMMdd hh:mm:ss
But if i take the piece of sql and run it from sql management studio, it will run without issue.
If you are at liberty to, change the service account to your own login, which would inherit your language/regional perferences.
The real crux of the issue is:
I use the following to convert -> date.Value.ToString("MM/dd/yyyy HH:mm:ss")
Please start using parameterized queries so that you won't encounter these issues in the future. It is also more robust, predictable and best practice.
I think the best way to work with dates between C# and SQL is, of course, use parametrized queries, and always work with DateTime objects on C# and the ToString() formating options it provides.
You better execute set datetime <format> (here you have the set dateformat explanation on MSDN) before working with dates on SQL Server so you don't get in trouble, like for example set datetime ymd. You only need to do it once per connection because it mantains the format while open, so a good practice would be to do it just after openning the connection to the database.
Then, you can always work with 'yyyy-MM-dd HH:mm:ss:ffff' formats.
To pass the DateTime object to your parametrized query you can use DateTime.ToString('yyyy-MM-dd HH:mm:ss:ffff').
For parsing weird formatted dates on C# you can use DateTime.ParseExact() method, where you have the option to specify exactly what the input format is: DateTime.ParseExact(<some date string>, 'dd/MM-yyyy',CultureInfo.InvariantCulture). Here you have the DateTime.ParseExact() explanation on MSDN)
It's a date format issue. In Ireland the standard date format for the 28th of March would be "28-03-2011", whereas "03/28/2011" is the standard for the USA (among many others).
I know that this solution is a little different from the OP's case, but as you may have been redirected here from searching on google the title of this question, as I did, maybe you're facing the same problem I had.
Sometimes you get this error because your date time is not valid, i.e. your date (in string format) points to a day which exceeds the number of days of that month!
e.g.: CONVERT(Datetime, '2015-06-31') caused me this error, while I was converting a statement from MySql (which didn't argue! and makes the error really harder to catch) to SQL Server.
You could use next function to initialize your DateTime variable:
DATETIMEFROMPARTS ( year, month, day, hour, minute, seconds, milliseconds )
JAVA8: Use LocalDateTime.now().toString()
i faced this issue where i was using SQL it is different from MYSQL
the solution was puting in this format:
=date('m-d-y h:m:s');
rather than
=date('y-m-d h:m:s');

How to set date to NULL in ODBC

I am using XOJO and pervasiveDB via ODBC.
There is a form that I need to update and on that form I have a date field that can be deleted on the form. When the date is deleted on the form, I need it deleted in the DB as well.
I am using ODBC, and can't do it for some reason. I have tried sending NULL, nil, 0000-00-00 and it is simply not doing it.
I have even tried not to send it if the date is deleted hoping for the best, but it will simply not go away.
Any ideas?
I think I resolved this issue. This is the solution:
The only working solution, after trying many different things.
dim inTYP as string = "6010-03"
SQLupdateBLIN = "update BLIN set inDAT=NULL WHERE inTYP= '" + inTYP +"'"
If I send the inDAT in following format (send it as variable), then it is not working (no error, just does not work):
dim inDAT as string = "NULL"
It seems ODBC is not liking variables that have value set to null.
Using direct SQL will definitely work.
If you are using a RecordSet, then you want to set the column to NULL using syntax like this:
MyRecordSet.Field("inDAT").Value = Nil
But whether this works is completely dependent on the ODBC driver.

JPA and SQLite3 - Wrong date

A date field in my entity class is defined as below:
#Temporal(TemporalType.TIMESTAMP)
#Column(name = "LAST_EXECUTED")
private Date lastExecuted = new Date();
However, when it is persisted to a SQLite3 database through JPA, the database value is always '1899-12-30'. Do you have any ideas why?
In the database, the field is defined as DATETIME.
I've tried using both SqliteJDBC and Xerial SQLite JDBC.
Update: After turning on SQL debugging in EclipseLink JPA, and turning off parameter binding, it looks like dates are inserted as following:
insert into run (last_executed) values ('{ts ''2012-02-17 10:34:58.013''}');
which, if inserted, manually in SQLite, gives the date '1899-12-30'.
Of course, any workarounds would be greatly appreciated.
The date looks correct in the insert, so seems to be some kind of SQLite issue. You should normally use parameter binding, it seems SQLite does allow Timestamp to be bound, or ignores the DATE portion. What if you use TemporalType.DATE?
Perhaps try through raw JDBC to see exactly what your JDBC drivers issue are?
For the printed syntax if not using parameter binding, you can customize this by creating your own DatabasePlatform subclass. The syntax you printed is the standard JDBC timestamp syntax.
Can you verify that it is a java.util.Date and not a java.sql.Date?
#Temporal(TemporalType.TIMESTAMP)
#Column(name = "LAST_EXECUTED")
private java.util.Date lastExecuted = new Date();
What does the debug output look like if you turn parameter binding back on?
Use smalldatetime solve the problem~~~ Try it.

Resources