It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
In my SQL Server table I have a column of datatype timestamp and I want to convert to DateTime in C#.
That's not possible.
"The timestamp data type is just an incrementing number and does not
preserve a date or a time."
http://msdn.microsoft.com/en-us/library/ms182776%28v=SQL.90%29.aspx
You can't. The timestamp data type is an alias for rowversion; its a binary incrementing value, its not composed of nor based upon a date & time.
The timestamp type is not a representation of a date or time but simply a generated number that is guaranteed to be unique in the database. As such, it can't be converted directly.
The only way to perform a rough conversion would be to periodically store the current time along with a timestamp in a new table, and then select which time is closest to the timestamp you want to convert from.
Alternatively you might want to add a new column to your table of type datetime, and update this whenever a row changes.
The Transact-SQL timestamp data type is a binary data type with no time-related values....., a timestamp is neither a date nor a time.So, you can't do..... See BOL:
timestamp:
timestamp is a data type that exposes automatically generated binary numbers, which are guaranteed to be unique within a database. timestamp is used typically as a mechanism for version-stamping table rows. The storage size is 8 bytes.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
This is date time format i want "2013-06-25 18:46:54.687" to pass in to sql server.
How to convert in C#?
DateTime LastUpdateTime=Convert.toDateTime(LastUpdateTime);
//2013-06-25 18:46:54.687 with 3 index of millisecond
sc.Parameters.Add("#LastUpdateTime", SqlDbType.DateTime).Value = LastUpdateTime;
You're using the wrong Data Typ in SQL.
The datetime2 can be considered as an extension of the existing datetime type that has a larger default fractional precision, and optional user-specified precision.
C# Format Milliseconds exactly the way you want.
In an Example:
DateTime date2 = new DateTime(2008, 1, 1, 0, 30, 45, 125);
Console.WriteLine("Date: {0:o}",
date2);
// Displays the following output to the console:
// Date: 2008-01-01T00:30:45.1250000
Look at Why is SQL Server losing a millisecond? and DateTime2 vs DateTime in SQL Server
These are great Question with good Answers, BTW.
If your database query parameter is string, use following format:
LastUpdateTime.ToString("yyyy-MM-dd HH:mm:ss.fff")
Otherwise, it would be better to send datetime as original object,
and let sql server do all conversions.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I am developing a C# application, and I have a date column in SQL Server.
I am performing a query based on date, using DateTimePicker. I have changed the format of datetime picker to short, now it displays date as mm-dd-yyyy
Now while executing I get correct output from date 1-12 but as soon as I select 13 date I get error as
conversion failed when converting date/time from character string
I don't know what is happening!
I suspect you're using the formatted string from that DateTimePicker to build an SQL query on the fly via format strings or concatenation.
Don't do that.
Date/time string literals in SQL tend to use a sane format (i.e. ISO 8601) where the order of the parts differs. The fact that it blows up when you change a piece from 12 to 13 should give it away, actually.
An SqlCommand has parameters (you can insert in the query with #foo. Using those will ensure that everything gets passed in the right way and properly quoted:
using (SqlCommand c = connection.CreateCommand()) {
c.CommandText = "Select roll_number,name from Attendance_table where date=#date";
c.Parameters.AddWithValue("date", dateTimePicker1.Value);
using (var r = c.ExecuteReader()) {
...
}
}
(roughly – you should consult the documentation for proper usage, it's been a while that I wrote such things)
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have a field that's stored in the database as a string. It's actually a comma-separated string of numbers that I convert to a list of longs. The lines of code that do the conversion look somewhat like this:
TheListOfLongs = (from string s in StringFromDB.Split(',')
select Convert.ToInt64(s)).ToList<long>();
The code that creates the database storage string looks like this:
return String.Join(",", TheListOfLongs.Select(x=> x.ToString()).ToArray());
This works fine but as you can see, if for some reason there's a problem with the string, the code in the first line of code breaks on Convert.ToInt64(s).
Now I know I can wrap all this around a try statement but my question is this: can storing and retrieving a string in the database corrupt the string (in which case I definitely need the try statement) or is this a one a trillion odd type of event?
I wouldn't worry about corrupt data per se. However, you definitely need to handle the more general case where you can't parse what should be numeric data.
Even in the most controlled situations it is good programming practice to provide conditions for when you can't process data as you're expecting to be able to. What that means to your application is something you'll need to decide. Wrapping the statement with a try..catch will prevent your application from choking, but may not be appropriate if the parsed list is critical later on.
Selecting from the DB shouldn't corrupt your string.
If the connection is dropped mid transfer or something like that then an exception is thrown.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
H iguys. I have a loop which parse users id's and adds tham to txt file.
What's the best way than to check if this txt has this id skip it ( while next parsing ).
The size of txt rises from 5-..... mb
I tried to add ids to List, but when the size of file if bigger than 5mb the app begins hanging
Use a HashSet<int> or HashSet<string>, collect the ids in it, then at the end write the result to the text file.
PS: Note that HashSet is O(1) while List is O(n)
You should probably load all of the IDs in the text file into some collection and check if that collection contains the IDs.
I honestly don't think that there's a much more efficient way of doing it than that.
A rule of thumb I believe is to trade time with space. If you want to make copying faster and avoid looking into the file again and again then you may maintain an array or linked list or hash table which also have the id stored in it
var userIsAlreadyThere = File.ReadLines(path).Contains(userid);
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have a WPF window which contains a textbox in which the user can enter a date in any format that he desires and i have to parse it in a datetime variable, simple enough? I tried various formats, some of them work with datatime.parse some don't, so what should i do about such strings?
some e.g. formats (year is not mandatory):
21 Sept
21st Sept
21 September
21st September
21 Sep
21/09
21-09
whatever catches the users fancy as long as it is a proper readable date, can anyone help me with this?
Update : based on comments, i am modifying the input string format....what if user can enter in any way but always day followed by month followed by year(optional).....is that manageable ??
Its not an answer but an Idea:
Why dont you use a Datepicker wo ou spare yourself alot of Job trying to convert every possible date to a valid one, and it looks nice too. Take alook at WPF Toolkit's Calender Datepicker Control
Its futile to do what you are doing.
A user can insert n number ways of adding date. How will you judge what format he has inserted.
Look for calendar controls because calendar is same everywhere and any user no matter where he is will insert correct date in it. In that case you can ask calendar for selecteddate or something kind of property.
There is no good answer to this problem, as best as I can tell.
DateTime.Parse still relies on the date being in a particular format. If you wanted - you could try multiple CultureInfos and hope that one of them works - but that would only work for a tiny subset of written dates real people would find acceptable.
Even if you wrote a lot of code to try and figure out all the possible ways regular people write dates - you'd still have globalization problems - some dates would be valid for interpretation in more than one way.
04/05 <-- What day is that?
Unless this is just for the sake of doing it; I think the best thing to do is simply provide a date-picker control or something similar that makes it easy for the user and gets you the date . Short of that - indicate the date format you expect.
DateTime.Parse works with the current CultureInfo unless you specify another info. Meaning:
21 Sept // invalid
21st Sept // invalid
21 September // acceptable by `en` CultureInfo
21st September // invalid
21 Sep // acceptable by `en` CultureInfo
21/09 // invalid by `en` CultureInfo (09/21 is valid)
21-09 // invalid by `en` CultureInfo (09-21 is valid)
But if you want a nice way for users to input a data consider using a control that will always catch a valid value instead of relying that a user will input the exact information you need manually.