Why my date is written 0000-00-00 - mysql

I have a table where the date column name is defined as proddate and defined as DATE.
Here is the code I write the value into table:
cmd.Parameters.Add("#Mydate", MySqlDbType.DateTime).Value = Convert.ToDateTime(MyArray[4]).ToString();
This gives a result of 0000-00-00
When I change it to
cmd.Parameters.Add("#Mydate", MySqlDbType.DateTime).Value = Convert.ToDateTime(MyArray[4]);
The result is correct. eg: 2013-11-14
However few lines down I have this code
cmd1.Parameters.Add("#date", MySqlDbType.DateTime).Value = Convert.ToDateTime(MyArray[4].ToString());
This gives no error. I get the correct result in table
And few lines after I have this code in the same method:
cmd3.Parameters.Add("#Mydate", MySqlDbType.DateTime).Value = MyArray[4].ToString();
This gives no error too
The last two lines I did the mistake for testing. But the columns of 2 last exemples are defined as DATE format
Any idea ? Or Am I welcome in the mystery world of Mysql ?
PS: I use MYSQL CONNECTOR 6.7.4.0 .NET3.5 and C# 2008 Express. In my server MYSQL is 5.0

In the first version, you're converting your value to a DateTime and then to a string, using the default format for a DateTime value. MySQL is then trying to parse that, and presumably failing.
In the second version, you're parsing your value as a DateTime, and supplying it to MySQL directly. This is the best approach, although you need to be careful about the input format you're using.
The third version is like the second, just with an explicit ToString call. If MyArray is of type string[], that's basically a no-op.
The fourth version is providing the string input directly to MySQL, which is presumably able to parse it itself. I would suggest avoiding that form though - parse it in the .NET code, where you have much more control.

Related

How to convert date from MM/dd/yyyy to yyyy-MM-dd in MySQL? Error Code: 1411. Incorrect datetime value: '' for function str_to_date

I have a large dataset with employees' time entries. The current date format is MM/dd/yyyy. However, I need to convert all the dates into yyyy-MM-dd format.
I have tried the following:
Update human_resources.timekeeping
Set Actual_Date = str_to_date(Actual_Date,'%d-%m-%Y');
Got the errror messsage Error Code: 1411. Incorrect datetime value: '' for function str_to_date.
My SQL version is 5.7.18-log.
I tried to view SQL mode using SELECT ##sql_mode; and I got NO ENGINE SUBSTITUTION.
I have tried to retrieve the value like shown below and it was working fine.
Converting varchar mm/dd/yy to date format yyyy-mm-dd
However, updating the data would not work. I need to update the actual records, not insert new records.
Hope someone can help me regarding this. Thank you in advance!
EDIT: The data type for Actual_Date is VARCHAR.
Apologies if my explanation may be a bit confusing. But I am using this data set to display and filter time entries in a gridview. When I am filtering dates, say for example (01/15/2022-01/25/2022), data from 2021 is also being displayed. When I tried to manually change the format of some of my data in sql to yyyy-MM-dd, my code seemed to be working fine. The problem is there are a lot of data in this table, which is why manually updating the format is impossible. What is the first thing that I need to do? I'm sorry this is all still a bit confusing for me.
My apologies if you have already taken the following things into consideration but I thought them worth mentioning.
Given that you say this is a "large dataset" I assume this is a table that is currently in use. Does the existing application rely on the Actual_Date being in that string format? Does it rely on a fixed number of columns in the table? Some poorly written applications can be very brittle when it comes to changing underlying data structure.
You may want to consider creating a copy of the current table, modifying the structure of the copy, and replacing the original with a view with the same columns and formats as the original. This way you get improved data but reduce risk to existing application.
In the title and first line of your question you state that the current format is MM/dd/yyyy
Update human_resources.timekeeping Set Actual_Date = str_to_date(Actual_Date,'%m/%d/%Y');
Your separator is / not -
%d-%m-%Y >> %d/%m/%Y

Query Expression not working after upgrading to Access M365

Why would this query expression stop working after upgrading from Access 2016 to Access M365?
Query Expression is BeginTime:
IIf(IsNull([BeginTimeOff]),"",CDate(Left([BeginTimeOff],8))).
What it does - takes time in SQL, if null, returns blank. If exists changes SQL time to long time.
Example - 13:30:00.0000000 changes to 1:30:00 PM (long time).
What changed in Access M365? Thanks!
The value 13:30:00.0000000 indicates, that it is stored as DateTime2. By default, this is read in Access as text, thus your conversion is correct:
CDate(Left([BeginTimeOff],8))
However, using an empty string, "", as parameter in IIf, forces IIf always to return a string, thus your converted date will be casted to text using the default time format of your Windows.
So, to have either Null or a true date value returned, either use Null as the parameter:
IIf(IsNull([BeginTimeOff]),Null,CDate(Left([BeginTimeOff],8)))
or reduce the expression using the good old CVDate as this (and also Left) accepts Null values:
CVDate(Left([BeginTimeOff],8))
The resulting DateTime value (or Null), you can format as to your preferences.
For some limited support in Access for DateTime2, go to:
Settings, Current database, last setting in right pane, and mark
Support date/time extended data type (DateTime2) for linked/imported tables
Thanks for all your answers! All would have worked - and some of them were in my original code. The issue wasn't the code - Access 2016 was 32 bit and Access M365 is 64 bit. I figured this out after receiving another error. After some searching, found a way to work around the issue.

Automatic conversion MySQL datetime to milliseconds on Apollo client?

I am using Apollo server and Apollo React client. The server runs a query against the MySQL database. In GraphQL schema I have defined the corresponding field sampleTime as String in the type Session. (There is no Date type in GraphQL.) But apparently some kind of default conversion is made on the way between the Apollo server and the result of useQuery. The field sampleTime shows the value as a number and not as a string. The number is apparently the JavaScript Date object.
In this case I don't need such a conversion. I found a solution on the server side by converting the SELECT output to the formatted string.
But why this conversion does occur at all?
Thanks

SSRS FormatNumber Error

trying to format number (decimal), but it shows me #Error on production server:
=FormatNumber(First(Fields!SumWithMailDelivery.Value, "document"), 0)
but on developers server it works fine.
Maybe someone know, how can i resolve this?
p.s. without formatting it works on production server fine too.
As #IanPreston says, it is most likely a type conversion error. I imagine your production data has some invalid characters for that column or some Null columns that make the numeric conversion fail.
You can use the Val function to do the conversion. Val differs from other numeric conversion functions in that it won't error when the string to be converted isn't numeric - it just does the best job it can.
So try an expression like this for the Value property:
=IIF(Fields!SumWithMailDelivery.Value Is Nothing,
Nothing,
IIF(IsNumeric(Fields!SumWithMailDelivery.Value),
Val(Fields!SumWithMailDelivery.Value),
Fields!SumWithMailDelivery.Value)
)
then use N0 as the Format property to format it as numeric if possible.
This formula will:
Leave the cell as Nothing if the field is Null
Convert to numeric and use the appropriate format if possible
Otherwise just output whatever is in the field

SSIS ISNULL to empty string

So I am currently working on a migration from an old Advantage database server to SQL 2005 using SSIS 2008. One of the columns in the old Advantage database is a MEMO type. By default this translates to a DT_TEXT column. Well in the new database I do not need this large of field, but can limit it to something such as VARCHAR(50). I successfully set up a derived column transformation to convert this with the following expression:
(DT_STR,50,1252)[ColumnName]
Now I want to go a step further and replace all NULL values with an empty string. This would seem easy enough using an ISNULL([ColumnName])?"":(DT_STR,50,1252)[ColumnName] expression, but the problem is that the OLE DB Destination contains the following error
Cannot convert between unicode and non-unicode strings...
So apparently the whole ISNULL expression converts the data type to Unicode string [DT-WSTR]. I have tried a variety of casts upon the whole expression or different parts, but I cannot get the data type to match what I need it.
First, is it possible to convert the DT_TEXT type directly to unicode? From what I can tell, the casts don't work that way. If not, is there a way to get an expression to work so that NULL values get converted to empty strings?
Thank you for all your help!
Give this a try in your derived column.
(DT_STR,50,1252) (ISNULL(ColumnName) ? "" : (DT_STR,50,1252) ColumnName)
It includes an additional type cast with the Conditional (?:) in parentheses to ensure the desired processing sequence. I think your original expression was implicitly casting to DT_WSTR because the "" defaults to DT_WSTR. With this new version, you force the cast to DT_STR after the expression is evaluated.
I figured something out that works. It may not be the best solution, but it will work for my situation.
From my OLE DB source I first did a Derived Column. This I used the ISNULL which ended up converting it to a DT_WSTR unicode type. although I could not get any casts to get it back to the type required, I then added a Data Conversion transformation in-between the Derived Column and the OLE DB Destination. This would take the input string and convert it back to a DT_STR. This all feels a little annoying converting so many times, but the column does not contain any funky information that I should have to worry about, so I suppose it will work.
Thanks for all those who pondered the solution, and if you find some awesome way to tackle it, I would be more than interested.