I recently copied a web application to a new install of Windows 7 and SQL Server 2008 R2. The application uses LINQ to SQL. Somewhere along the line the parsing of POSTed date strings got screwed up. When the user enters a date string like 4/23/2011, the application rejects it, throwing the error The value '04/23/2011' is not valid for Due. Due (actually DueDate) is a DateTime field in SQL Server.
This used to work fine. I assumed it was an issue with the machine's OS internationalization settings, so I checked and the short and long date formats are set to MM/dd/yyyy and dddd, MMMM dd,yyyy respectively, which looks OK to me. The SQL Server database language is set to English.
The partial class for this property looks like this:
[DisplayName("Due")]
[DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:MM/dd/yyyy}")]
public DateTime? DueDate { get; set; }
There must be another date format setting I need to tweak. Where should I be looking?
Note: this may be more correctly a serverfault question, but I think devs are much more likely to run into this issue than sysadmins.
More info: SP_CONFIGURE 'default language' returns:
default language 0 9999 0 0
Also: the default language for the database login I am using is English.
I assumed it was an issue with the machine's OS internationalization settings
No, it uses th USERS internationalization settings as told the server by the browser.
the application rejects it, throwing the error The value '04/23/2011' is not valid for Due.
And that is purely bad programming. You should always (!) enter dates either through a parameter or in the ISO form which is totally independant, if you really insist on creating your SQL strings yourself. That woudl be 2011-04-23. SQL Server will accept that format regardless of the locales set somewhere on client or server.
Related
I'm working on moving an old asp code to .net.
on the strCon (the connection to the database) one of the parameter is:
strCon=".....;CCSID=1255;"
I'm not sure what that means, I researched online but didn't find anything.
Can anybody explains what that means?
Per Wikipedia, CCSID means "Coded Character Set Identifier". Which sounds a little like "code page" and Windows has a codepage 1255 for Hebrew. If your application deals with text data that's in Hebrew, this may be the reason for it (but read the next paragraph!).
It may be legacy cruft left over from an old database or driver which handled different encodings via the connection string - it's not a standard parameter in SQL Server connection strings. See https://www.connectionstrings.com/all-sql-server-connection-string-keywords/ and https://msdn.microsoft.com/en-us/library/ms130822.aspx
Try removing that portion of the connection string; it may not be needed. The only way to be sure is to test.
We have been using the following SQL query for a long time in a WinForms program with no problems, until some end users upgraded to Windows 10.
They suddenly get the exception:"ERROR [22007] [Microsoft][SQL Server Native Client 11.0][SQL Server]The conversion of a varchar data type to a datetime data type resulted in an out-of-range value."
This error has been posted to inside here earlier, but I did not find any post where the occurrence was connected to a Windows 10 upgrade.
The query is targeted to a SQL server 2012, using Native Client 11. It works on windows 7 and 8, but throws exception in Windows 10:
SELECT DISTINCT tblEmployee.EmployeeID, tblEmployee.Lastname, (COALESCE(tblEmployee.Firstname, '') + ' (' + COALESCE(tblEmployee.EmployeeIDText, '') +')' ) AS Firstname
FROM tblEmployee
LEFT JOIN tblAssignmentService ON tblEmployee.EmployeeID = tblAssignmentService.EmployeeID
WHERE tblAssignmentService.ServiceDate >= '2015-08-31 00.00.00'
AND tblAssignmentService.ServiceDate < '2015-09-07 00.00.00'
ORDER BY tblEmployee.Lastname;
The only place where DateTime fields are used is in the Where clause, and the query works fine against the same DB with a windows 8 client. Both clients run Einglish Windows versions. Another interesting observation is that the query is accepted from Microsoft SQL Management Studio on the Windows 10 machine. But not through the native client. The dates used in the filter is created in our program through a GUI.
Have somebody else experienced strange things with Native Client on Windows 10, or does anyone have a suggestion to how this problem may be solved?
I confirm that the solution purposed in this thread solved my problem.
After some research we found that the ToString("yyyy-MM-dd HH:mm:ss") call responded differently in Windows 7 and Windows 10 if the current culture was set to "no" or "nb-NO" at runtime (Thread.CurrentThread.CurrentCulture = new CultureInfo("no");).
The suggested modification did the trick: ToString("yyyy-MM-dd HH:mm:ss", CultureInfo.InvariantCulture). This solves my problem, as the dots in the time formatting was its root cause.
But should ToString("yyyy-MM-dd HH:mm:ss") return different formatting in the same culture depending on OS? :O This is kind of scary.
We have our application developed and tested with sql server 2008r2 using ASP.NET on windows server. Now we have a requirement to move the database from windows to oracle on red hat linux.
We haven't yet setup the infrastructure to test the same. I would like to know in the meantime if anyone has successfully done this kind of thing. Pointers to any resources will be a great advantage.
Is changing the connection string the only thing that needs to be done or are there any specific configuration in Linux to allow this?
I will verify this once I get the environment ready, but as a headstart if anyone has any similar experience, do share.
Thanks in advance.
P.S: For migration of table structure, storedprocedures etc to oracle we will be using the Sql Developer tool.
I would like to answer my question,because, migration to oracle is not that straight forward, but there are some tips that may help anyone migrate to oracle on windows or linux with less headache.
The first thing the Sql developer tool does a good job of migrating sqlserver schema and data to oracle including storedprocedures, constraints, triggers etc.
It also does a good job of datatype mapping and provides option to remap datatype if required.
Some caveats and precautions.
Oracle has a limitation on the length of stored procedure names of about 30 characters. This is the area you need to resort to some manual renaming as when migration SP's or identifiers whose name is greater than 30 characters may get truncated.
The other common issue that you may face is respect to date insertion and formatting. You can use the following snippet to avoid the headache. The common error will be "Not a valid month."
OracleConnection conn = new OracleConnection(oradb); // C#
conn.Open();
OracleGlobalization session = conn.GetSessionInfo();
session.DateFormat = "DD.MM.RR"; // change the format as required here
conn.SetSessionInfo(session);
The most annoying error would be well character to numeric conversion when inserting or updating data or related error.
The issue here is when you add parameters to command object for sql provider, the binding happens by name, but forOracle.DataAccess the default binding is by position. Here's the post that saved me lot of headache.
ODP .NET Parameter problem with uint datatype
What you can do is set the command.BindByName = true;
When migrating SP's that returns data, oracle creates an out parameter ref cursor. This needs to be taken care of while constructing command parameters.
For e.g.
OracleParameter refp = new Oracle.DataAccess.Client.OracleParameter("cv_1", OracleDbType.RefCursor, ParameterDirection.InputOutput);
command.Parameters.Add(refp);
Also the sqlserver requires parameters to SP be prefixed with "#" and oracle doesn't. This can be easily taken care of in your data layer.
Also since there is no bit datatype in Oracle, number(1) works fine. You may need to convert your bool to numeric, if required.
Hope this helps someone avoid a migration headaches. I will post more issues if I encounter.
I've got a site using .netCART. It's running fine in production with Windows Server 2003 and .NET 2.0. On the new server (Windows Server 2008) everything is working except for credit card decryption in the store admin. No errors are being sent, no exceptions thrown, just the encrypted string being output to the screen instead of a decrypted credit card number.
Dim strCCEncrypt As String
strCCEncrypt = Trim(DataRow.Item("CreditCard"))
strCCEncrypt = tools.Decrypt(strCCEncrypt) 'tools is a .netCART utility
Has anyone had experience with .netCART, or seen this issue before?
EDIT:
After much investigating yesterday, it seems as though the problem is tied to the App Pool (which is running in classic pipeline mode on .NET 2.0), and Decryption. Can anyone tell me what the processes or services are that are tied to the default app pool which help handle decryption?
Don't know where your specific problem is, but that code snippet is equivalent to this:
Dim CCEncrypt As String = tools.Decrypt(DataRow("CreditCard").ToString().Trim())
To explain the changes:
You can skip the .Item part because it's an indexer for DataRow
But you should call .ToString(), in case of other types or DbNulls
Then use the string type's .Trim() method rather than the VB Trim() function. Trim() and other old string functions exist solely for backwards compatibility. You're better off becoming accustom to the methods attached to the string type.
In .Net, it's no big deal to declare a variable and assign to it on the same line
And in .Net, Microsoft's style guidelines specifically recommend against any hungarian-notation type warts on variable names.
The end result of this problem was that I used Reflector to get the method out, provide the key manually to perform the decryption, since the decrypt method shown above just provided a call to a method that took the key.
Check the machinekey element in your web.config. Is it possible the credit cards were encrypted with a different key than you are trying to decrypt them with?
When you startup a standard trace the first settings you see will be the current database connections.
In my case there is about 10 entries, all of whome are the same username, however some are dateformat dmy and some are mdy. The asp website seems to pick a connection from the pool and uses it, it appears to pick one of 3 and all are set to dmy however every connection should be mdy. Since they are all the same username and that user is set to us_english where else might the connection be getting the dateformat entry?
Thanks
Some ideas:
The application is issuing SET DATEFORMAT
The app is using a DSN with/without translation
By default, the connection default is defined by SQL Server default settings.