I have a report choosing start date and end date.
I tested at the office and it is working fine.
When it is installed at the user's place, the following error pops up.
I wonder why is that?
I bring back the database and run at the office.
Still working fine.
Well, it's not a parsing problem in DateTime.Parse, which is what I first expected. Your code (Form1.Calculat) is calling the constructor directly, so you should be able to log what values you're trying to use to create the DateTime, along with which row of the database is causing the problem.
We can't really do any of that diagnostic work for you, but once you've worked out what the values are, you should look through your code to work out where they're coming from.
Does your client have a different default culture to your development machine? That's normally the first port of call - but unless you're manually parsing date/time strings into their constituent bits, I wouldn't have particularly expected this failure mode.
If you could post some code, that would really help.
Are you passing the values to the TimeToTicks method ?
Probably these values are not forming a valid DateTime. Why it works on your office PC might be because you have different culture settings.
For example, in one culture "11/25/2010" is a valid date as the format (MM/dd/yyyy), but on a different culture, where date format is set as (dd/MM/yyyy) it will not be a valid date.
You can change the system date format from the control panel or modify your code accordingly. Hope this helps.
I think it is most of a problem Culture specific rather than any other issue. At one system the date format would be MM/DD/YYYY and at other system it would DD/MM/YYYY or something like that. So the datetime object should be picked culture specific and values should be passed that way as well.
Hope it fixes the problem.
Related
We have an web application in C# in where we have multiple pages with reportviewer controls, and almost all of them have date parameters.
That date parameters are rendering a datepicker (everything it's fine till this point, no exceptions, no problems) but all the datepickers starts on Sunday ("domingo" in spanish, "do" abbreviated) and our client complains about it; he wants it to start on monday ("lunes" in spanish, "lu" abbreviated).
Accessing the same reports from reportserver works fine, all the datepickers starts on monday("lu") and it works fine:
I've checked that user's Culture and CultureUI it's correct (es-ES for spanish culture); and i think that's working fine cause today's text and day names are properly translated...
I've Googled it and i have only found that if you change DATEFIRST in SQL it must be solved; but it doesn't.
Can anyone give me a clue or any solution?
I know that i can use my own parameter selectors and call the reportViewer only to load the report with the parameters, but this solution will take a long time and we prefer to avoid that solution.
I've also read that with Reflection i can access the Datepicker class inside Microsoft.Reporting and change it to start on monday; but it's not a "nice" solution and it's really complex.
I've had similar trouble with date-format on the client. The doco says that it should determined by the Language of the report, so set that to the language of the client (see below). You could even be more specific and set the language to es-ES
But I've found this approach does not always work. (for me at least). Once the report is set up like this, changing the client locale, should change the date format (and start day of week).
At one point changing the locale of the SSRS server had the desired effect (but this is a pretty sweeping change)
I have an application which I developed in the UK. I have now deployed this to a US server and the dates are incorrect. I have a date time picker which I have set the format to be dd/mm/yyyy, when I select the date time picker I notice that when I inspect the element the date is actually 12/10/2013.
When I store this to the database this is being transformed as 2013-12-10 and then when I retrieve this from the database it is actually 10/12/2013.
Also when I call DateTime.Now in the code this is coming back as a US format (mm/dd/yyyy). I need everything to be consistent. How?
I have tried setting the culture info in the web config <globalization uiCulture="en-GB" culture="en-GB" /> but this is having no effect, some areas i am storing the date in sql server as GETDATE() and sometimes this is passed in as DateTime
I don't actually think you're dealing with incorrect behavior, you're most likely dealing with different TEXT representations of the SAME underlying DateTime or DATE item:
If Visual Studio is running on a system with en-US regional settings, it's insepectors will obviously use those settings when displaying dates in the debugger.
If you're looking at an SQL column with a data type of DATE, SQL might use the "SQL" standard representation for string, and that's why you see "2013-12-10"
When you're using Object Inspector to inspect the DateTime value selected into a control, Visual Studio is again using the system's settings to display that date. It can't show you the actual binary representation.
The crust of the problem:
Make sure you differentiate your actual date (stored in a DateTime variable or a DATE database column) from it's TEXT representation.
Make sure you get the correct date.
Make sure your application's users see the date in the expected format.
Learn to deal with the text representations of date that only you as a developer would see (the SQL-style representation and the Visual Studio inspector representation).
I have a software developed in C#, which is a pure sentefic application. Howver the German users found this software stopped working from time to time, when it is installed on German computers. The temporary solution is to change the Language setting in the control panel, and it works fine after we change the language setting from German to English. This is just a kind of engineering sofware, and the software have nothing relalted to the German or English language. Also, as suggested from other posts in msdn, I have checked the "InitializeComponent()" in the source does several times. There are not strange codes in the "InitializeComponent()" function.
When you change locale, you change the meaning of ',' (comma) and '.' (full-stop) when used in numbers. Could it be that you are trying to parse text containing these characters into numbers?
Does your program attempt to initialize numeric fields with formatted numbers, perhaps?
You need to make sure that your code is sensitive to the user's culture when parsing and formatting text. You also need to make sure you use a consistent culture (e.g. the InvariantCulture) when reading data stored to file or sent over a network.
If you are using .NET Framework 4.5, you might be interested to read about the CultureInfo.DefaultThreadCurrentCulture Property.
In the .NET Framework 4 and previous versions, by default, the culture
of all threads is set to the Windows system culture. For applications
whose current culture differs from the default system culture, this
behavior is often undesirable.
The examples and their explanations on the page could be quite helpful for your issue.
Also, as a side note, try{...}catch{...} blocks are always welcome.
I am working on a project for my company, and while tracing previously written code I came upon this:
<value>A payment authorization for {0:C} has been received.</value>
What does {0:C} mean? I have been trying to find out and am having no luck.
This is just a string like any other string. Once loaded into memory, it will be used as the format parameter to string.Format. {0:C} just means to format the number as currency using the current UI culture (or is it just current culture? I can never remember).
It's formatting a number as currency.
I would like to put the date the application was built somewhere in the application. Say the about box. Any ideas how this can be done? I need to do this for C# but I am also looking for a general idea, so you can answer this for any specific language other than C#.
Typically we just go with the executable's last modify date. This will be set when the exe is built and usually never changes (short of someone actually editing the file). When the file is installed, copied, moved, etc, Windows doesn't change that value.
DateTime buildDate =
new FileInfo(Assembly.GetExecutingAssembly().Location).LastWriteTime;
We use this technique for the about dialogs in our C# and C++ apps.
The third number of the assembly version is a julian date with 0=1 Jan 2000 if you're using [assembly: AssemblyVersion("1.0.*")]
e.g.
DateTime buildDate = new DateTime(2000,1,1).AddDays(
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Build
);
You should be using version control - Subversion is free. Then you could include a number from the version control system that would unambiguously identify the source code used to build the app. A date won't do that. There are other advantages too.
Full history of all changes to the project.
Work seamlessly with other developers on the same project.
EDIT: Nikhil is already doing all this. But for some incomprehensible reason he has been told to include the date as well. I'm going to leave this answer here anyway, for future readers of this question.
There are usually keywords in your source code control system for this sort of thing.
Otherwise, look at including the date and time in the version number, or simply creating a small source code file which contains the date and time, and gets included in the build