I use a query that takes in a datetime parameter such as:
SELECT * FROM Table WHERE logindate=#logindate
Then I used parameter to pass in the #logindate value in C#
command.Parameters.AddWithValue("#logindate",DateTime.Now.ToUniversalTime());
In my local, it works fine, but it gives error in my friend's local PC:
Arithmetic overflow error converting expression to data type datetime.
We've tried many methods including Convert.ToDateTime but failed. When we checked in the debugger,
Datetime x = DateTime.Now.ToUniversalTime();
my PC gives "11/21/2012" whereas my friend's PC gives "21/11/2012" as the date. We've tried changing the date time of the PC, and checked the IIS 7.5 settings installed in our PC. Is there something else that we should check?
Related
There is an external application which we get from our external suppliers, lets say the executable is a file named "SomeApplication.exe".
In a past version of this application, when it was started and I was looking in Taskmanager->Processes, I saw it appearing in 8.3 format with the name "SOMEAP~1.EXE".
Now we got a newer version, and in this one, in Taskmanager it is displayed normally as "SomeApplication.exe", exactly like the file name and as I would expect it.
To make it clear again: Same filename, one time process name appears in long format, one time on 8.3.
Can someone explain this behavior to me? Is it somehow controllable from implementation-side or OS-side how the process name appears?
PS: OS is always Windows Server 2008 R2 64Bit.
Recently I started working on VS2012.
When I debug my code (this is a SharePoint 2013 application) and trying to get the value of variables - I get again and again the message:
Function evaluation disabled because a previous function evaluation timed out.
You must continue execution to reenable function evaluation.
I previously worked in visual studio 2010 (for SharePoint 2010 applications) and almost never got this message while trying to get the value of variables in the Quick Watch.
I Googled the error message, and I saw that the problem occurs when trying to get a value of functions whose action takes a long time,
But I'm not trying to get a value of functions, only variables, and yet I get this error.
I do not always get the error on the same variables, but random - each time different variables.
Is anyone else having this problem specifically in VS2012?
And how can I get rid of it?
Why this is happening ?
It seems this kind of bug can happen simply when you are trying to watch at some variables who have to be thread safe but sometimes this framework implementation is not perfect....
To avoid this problem : when stepping through code where variables are bound to windows or other controls, you don't show local variables or "auto" variables. Look at such things only when you are sure your variables are all safe to look at. And note that the error doesn't necessarily appear on the unsafe variables. Use the "immediate" window on safe (i.e. non-control) variables when operating in dangerous code.
Data accessors should always be thread safe. But sometimes between two implementations (let's say between Sharepoint 2010 and Sharepoint 2012 or two version of the .NET framework), this rules is sometimes not true... There is some examples between VS2003 and 2005...
How can I increase the timeout ?
You can increase the timeout by changing the values of the registry Key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\Debugger using RegEdit.
Don't forget to restart Visual Studio after changing the registry key.
I am clueless about a recent issue that I encountered while making an MSI installer for Windows XP 64 bit platform.
In the Launch condition of the installer I am trying to read from registry, but the installer is not fetching the correct value. I tried checking for a different Value name, to confirm that its not just one particular Value name, and found it's behaving in the same manner.
I tried to print the fetched registry value data in the error message and realized that in some cases it gets no value at all and in other cases, it fails to get any number that is a part of the complete value data.
For example if try reading the data for:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
Value Name : InstallRoot
Value Data: C:\Windows\Microsoft.NET\Framework64\
The data that installer fetched is: C:\Windows\Microsoft.NET\Framework\. And in some other instances it gets an empty string.
Registry searches use the 32-bit registry hive by default and the 64-bit hive only if msidbLocatorType64bit flag is set.
So the solution is to use 2 searches with the same property:
one for the 32-bit hive
one for the 64-bit hive (with msidbLocatorType64bit flag)
Please note that Visual Studio setup projects do not support this. Other setup authoring tools do.
Within a VB.net program I used IO.File.GetCreationTime to read the file system's creation time of a file. I was irritated, because the returned value didn't match with the time displayed in the explorer. On another machine the time was displayed correctly.
Both machines use NTFS
I copied the file from a read-only FAT32 USB-drive to the desktop of each machine
Both machines are using the same time zone (GMT+1 plus DST)
timestamps displayed:
my VB.net app (both machines) - 21:09
Explorer time Windows XP - 22:09
Explorer time Windows 7 - 21:09
(MacOS X - 21:09)
The good thing is, that the file I'm talking about is a PDF file. According to the PDF's meta information the file was created on 03. Jan. 2002 22:09
I want that the file system dates are the same on every machine.
How would you solve this problem using VB.net?
I used a simple app to summarize the timestamp information:
GetLastWriteTime(file)
GetLastWriteTimeUtc(file)
GetLastWriteTime(file).ToLocalTime
GetLastWriteTimeUtc(file).ToLocalTime
GetLastWriteTime(file).ToFileTime
GetLastWriteTimeUtc(file).ToFileTime
Date.Now
Date.Now.UtcNow
The output was the same on both machines.
For some reason I changed the time zone settings on both machines, switching DST on and off. The result is interesting ...
... when you turn off DST on Windows
XP all time stamps are reduced by
one (because during DST my time zone
is GMT+2 (now), during the
wintertime it is GMT+1)
... on a Windows 7 machine only
files created during DST (GMT+2)
are affected by this (my file was
created in January)
I guess it's the same effect vice versa. So my problem is just a disply issue. To solve this I will only use the UTC-Functions and care about DST within my app. So there still will be an offset, but it should be ok as long as it is just a display issue.
The Win32_Printer class returns a field per printer called Default (a boolean value). This works locally and accurately returns the Default printer. However when remotely connecting in with WMI, it always returns false.
I thought it could depend on the user with which you did the remote WMI query. However, that's not the case (I tried it with different users and no change).
Is there anyway to fix this? I'm currently trying to get this to work on a Windows 7 client and i'm connecting to it from a Windows 2008 R2
I can see that this thread is quite old but I thought I'd add my 2 cents worth even if though it's of no help, but this same issue is there with XP too. In fact under XP you can't read the Win32_CDROMDrive stuff either, although it's fixed under Windows 7.
Have you found an answer to the default printer issue with WMI? As an alternative you can read the default printer but not the port from the registry as in:
hkcu\software\microsoft\windows NT\CurrentVersion\Windows\Device
It'll show something like HP Color LaserJet CP3525 PCL6,winspool,Ne03:
Trim the crap and you've got what you need. Now you've got the printer you can get the matching port via WMI.
Regards,
4Eyes