2 web servers using the same database. One is throwing date out of range error - sql-server-2005

I am moving a classic asp website from a windows 2k3 server/iis6 environment to windows 2008r2/iis7. A couple of the pages pass the system date to an mssql database and the following error is occuring: The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value. The date being passed is '13/01/2011 hh:mm:ss AM'. I understand that the database is interpretting this as the 13th month and that is why the error.
What I don't understand is where exactly this date is coming from. The page is using this snippet for the date:
FormatDateTime(DATE() & " " & Time(), vbGeneralDate)
This should return a date in the format mm/dd/yyyy but it doesn't seem to. Since web servers are using the same database I figure the problem must be web server specific.
I checked in control panel/regional settings and both are set to US english and the format there appears to be correct. Is the system date & time formats specified anywhere else? I could not find anything in IIS where I could set a default date format

i think you need a Session.LCID(=LCID) line in your code.
more on this:
http://www.w3schools.com/asp/prop_lcid.asp

The problem ended up being the system locale setting found in control panel --> region and language. This setting "controls the language used when displaying text in programs that do not support Unicode."

Related

ArcGIS url query using date parameter stopped working overnight

Until a few days ago, this query ran without problems:
https://dhsgis.wi.gov/server/rest/services/DHS_COVID19/COVID19_WI_V2/MapServer/11/query?where=RptDt>='2022-05-01'&outFields=*&returnGeometry=false&outSR=4326&f=json
Now it returns:
error
code 400
extendedCode -2147220985
message "Unable to complete operation."
details []
The URL without RptDt specification still works just fine:
https://dhsgis.wi.gov/server/rest/services/DHS_COVID19/COVID19_WI_V2/MapServer/11/query?where=1%3D1&outFields=*&returnGeometry=false&outSR=4326&f=json
Here is a link to the open data portal resource.
The trouble appears to be in this bit: where=RptDt>='2022-05-01'.
Did ArcGIS change the formatting for date values? Does anyone know how I can update my URL to work properly?
If you change the date query to use a standardized date format it seems to work fine, ie using RptDt>=date'2022-05-01' instead of RptDt>='2022-05-01'.
Updated example URL: https://dhsgis.wi.gov/server/rest/services/DHS_COVID19/COVID19_WI_V2/MapServer/11/query?where=RptDt%3E=date%272022-05-01%27&outFields=*&returnGeometry=false&outSR=4326&f=json

Customized cultures cannot be passed LCID, only by name, Parameter name: culture

I'm using crystal report in my VB.net application, when I show the Report and try to print it I face this error :
Customized cultures cannot be passed LCID, only by name, Parameter name: culture
The printing works fine on my computer but the problem on client computer.
this the error picture :
after searching, I found the solution :
By change the region settings of the operation system to a format whose LCID does not equal 4096. The format can be changed in Control Panel > Region > Formats.

DBD::Oracle, Cursors and Environment under mod_perl

Need some help, because I can't find any solution for my problems with DBD::Oracle.
So at first, this is the current situation:
We are running Apache2 with mod_perl 2.0.4 at our company
Apache web server was set up with a startup script which is setting some environment variables (LD_LIBRARY_PATH, ORACLE_HOME, NLS_LANG)
In httpd.conf there are also environment variables for LD_LIBRARY_PATH and ORACLE_HOME (via SetEnv)
We are generally using the perl module DBI with driver DBD::Oracle to connect to our main database
Before we create a new instance of DBI we are setting some perl env variables, too (%ENV). We are setting ORACLE_HOME and NLS_LANG.
So far, this works fine. But now we are extending our system and need to connect to a remote database. Again, we are using DBI and DBD::Oracle. But for now there are some new conditions:
New connection must run in parallel to the existing one
TNSNAMES.ORA for the new connection is placed at a different location (not at $ORACLE_HOME.'/network/admin')
New database contents are provided by stored procedures, which we are fetching with DBD::Oracle and cursors (like explained here: https://metacpan.org/pod/DBD::Oracle#Binding-Cursors)
The stored procedures are returning object types and collection types, containing attributes of oracle type DATE
To get these dates in a readable format, we set a new env variable $ENV{NLS_DATE_FORMAT}
To ensure the date format we additionally alter the session by alter session set nls_date_format ...
Okay, this works fine, too. But only if we make a new connection on the console. New TNS location is found by the script, connection could be established and fetching data from the procedures by cursor is also working. Alle DATE types are formatted as specified.
Now, if we try to make this connection at apache environment, it fails. At first the datasource name could not resolved by DBI/DBD::Oracle. I think this is because of our new TNSNAMES.ORA file or rather the location is not found by DBI/DBD::Oracle in Apache context (published by $ENV{TNS_ADMIN}). But I don't know why???
The second problem is (if I create a dirty workaround for our first one) that the date format, published by $ENV{NLS_DATE_FORMAT} is only working on first level of our cursor select.
BEGIN OPEN :cursor FOR SELECT * FROM TABLE(stored_procedure) END;
The example above returns collection types of object which are containing date attributes. In Apache context the format published by NLS_DATE_FORMAT is not recognized. If I use a simple form of the example like this
BEGIN OPEN :cursor FOR SELECT SYSDATE FROM TABLE(stored_procedure) END;
the result (a single date field) is formatted well. So I think subordinated structures were not formatted because $ENV{NLS_DATE_FORMAT} works only in console context and not in Apache context, too.
So there must be a problem with the perl environment variables (%ENV) running under Apache and mod_perl. Maybe a problem of mod_perl?
I am at my wit's end. Maybe anyone in the whole wide world has a solution ... and excuse my english :-) If you need some further explanations, I will try to define it more precisely.
If your problem is that changes to %ENV made while processing a request don't seem to be honoured, this is because mod_perl assumes you might be running multiple threads and doesn't actually change the process environment when you change %ENV, so external libraries (like the oracle client) or child processes don't see the change.
You can work around it by first using the prefork MPM, so there aren't any threading issues, and then making changes to the environment using Env::C instead of the %ENV hash.

DGRAPH Log report DocumentCollectionCategories::GetDocumentScore invalid parameter

I'm looking at our Dgraph.log file and I'm seeing a lot of the following errors. Can anybody point me towards the cause of it? I've verified that my property "p_sort_default" exists and is being populated with data. I'm not sure how to track down where it's being used as a parameter incorrectly.
ERROR 01/02/14 06:02:50.414 UTC DGRAPH {dgraph}: DocumentCollectionCategories::GetDocumentScore invalid parameter "p_sort_default".
This error is due to using a search interface with a dimension search. The search interface was designed to be used with a navigation query which have the parameter "p_sort_default". The dimensions do not have the parameter and are throwing the error. We are setting up a new search interface specific for the dimension search to use to clear up the error.

How do I check to see if the license expired on my app?

I am creating an application in VB.NET (for windows) in which the license expires after a year. What date can I use that the user can not manipulate to see if a year has gone by?
I don't want the user to have to be online to use the software, so an online check is not a valid option.
Thanks.
A date based expiry without NIST (network time servers) is precarious because the only alternative is the local clock, which the user can fiddle with. Checking once in a while, such as every week or two, presents a very large vulnerability: This requires the app write down the date of the last check somewhere and it is simply impossible to keep that a secret on the user's machine.
One way to get the approximate date is to calculate it from the last boot datetime:
Public Class WMI
Friend Shared Function GetWMISetting(wmiClass As String, value As String) As String
Dim retVal As String = ""
Dim query = String.Format("SELECT {0} FROM {1}", value, wmiClass)
Using searcher As New System.Management.ManagementObjectSearcher(query)
For Each item As System.Management.ManagementObject In searcher.Get
For Each p As System.Management.PropertyData In item.Properties
If String.Compare(value, p.Name,
StringComparison.InvariantCultureIgnoreCase) = 0 Then
If p.Value IsNot Nothing Then
retVal = p.Value.ToString
End If
Exit For
End If
Next
Next
End Using
Return retVal
End Function
Friend Shared Function GetMinSystemDateTime() As DateTime
Dim lastBoot = WMI.GetWMISetting("Win32_OperatingSystem", "LastBootUpTime")
Dim uptime = WMI.GetWMISetting("Win32_PerfFormattedData_PerfOS_System",
"SystemUpTime")
Dim ts As New TimeSpan(0, 0, Convert.ToInt32(uptime))
Dim MinimumDate = ManagementDateTimeConverter.ToDateTime(lastBoot).Add(ts)
Return MinimumDate
End Function
End Class
The calculates the approximate date from the LastBootUp date, and the SystemUpTime values. The latter can be seen on the Performance tab of TaskManager. The date format is peculiar, so the System.Management namespace provides a converter.
The Date returned is approximate because the "UpTime" does not include time sleeping. Otherwise, it gives you an idea of the approximate minimum date.
They could probably spoof this using a VM, and it could be totally wrong if the battery is dead, they wont let Windows set the time so the PC is permanently off date. If your license includes an install/issue date (set by you at the Home Office, not the client PC), you could test if the Date returned is less than the install and treat that as expired.
Then the trick becomes protecting those values. When you issue the license, serialize the user name, serial, install date and expiry date to a MemoryStream. Then run a RSA hash on the data to create an asymmetric signature.
Create a class to hold the license data as a base64 string and the signature hash and serialize it to a file. At runtime, open it and validate the signature using the license data and the Private Key. If it validates, the data in the "license" portion is valid.1
Ultimately, they really just need to patch your code:
' from:
IsRegistered = ValidateLicense()
' to:
IsRegistered = (True = True)
Obfuscate your app to slow them down on that.
Now, if you think something like that will thwart say, 80% of your likely user base, then go for it.
The the user can not manipulate part is not do-able, but you can concoct a solution that will work to a fair degree. WHO you are trying to keep out (crackers vs super users vs AOL-LoLs) determines how extensive or sophisticated you need to be.
1 Such a file is read only on the client. You cant write to it without invalidating the signature. And you cannot update/change it without including the Private Key in the app which is suicide.
If you are not willing to look at an online clock/service/etc, this cannot be done, because the user can change the time, whenever they want and you cannot prevent it.
You can however, check for tampering by using 2 dates. One for the expiration and one as a check for tampering. Everytime they load your app, it should always be > Expiration Date - 1 year and it should be greater than last time they started your app. Of coarse, you want these encrypted so they cannot tamper with these dates.
This makes it where it becomes more of a hassle than it is worth for the user and they eventual will get locked out, it just might take another year, but it will happen.
Think about this issue, what will prevent them from removing your file/registry setting and starting over. How about formating thier hard drive or doing a system restore. Perhaps they use a virtual PC or some type of undo disks. How do you overcome this?