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.
Related
My office recently did some migration of servers, and as a result our webpages now use different data sources. For our environment, we typically use SQL Server, though we also have a linked server to an Oracle database. I am having difficulty finding out where I need to update the username and password for one of our web pages.
Generally speaking, the process has been pretty easy: go to Web.Config, find the connection string that the page is using, and update it with the relevant data source, username, and password. This page, however, is different. First, I get this error when visiting the page:
ERROR [28000] [Oracle][ODBC][Ora]ORA-01017: invalid username/password;
logon denied
ERROR [IM006][Microsoft][ODBC Driver Manager] Driver's
SQLSetConnectAttr failed
ERROR [28000] [Oracle][ODBC][Ora]ORA-01017: invalid username/password;
login failed
Okay, so obviously I need to update the password somewhere. I go to Web.Config, and I don't see any connection strings. This is a first for me, so I start looking around, and the only thing I see (worth mentioning) is this line:
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1; Trusted_Connection=yes" cookieless="false" timeout="20"/>
To me, this indicates that the database is local, or at the very least my problem lies on the webserver itself. So I remote in, and I check both the ODBC connections for Oracle and SQL Server; no issues. Each of them work. I even check the 32-bit and 64-bit connections.
Googling "Driver's SQLSetConnectAttr failed" tells me it's the ODBC issues, but again...I can't find anything.
Does anyone have any ideas on why I keep getting these errors and what I can do to fix it?
I (well, technically my coworker) found the answer. The answer lied within IIS. Basically, we were missing two connection strings. The first one references the driver, and the second one (I believe) contains the username/password that is passed to the ODBC driver through the first connection string. Whereas normally the connection strings are stored in the program (web.config file), in this case it was on the actual server. The program looked for the connection strings there, but couldn't find it.
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 am new to ASP. I have two databases production and developer databases.
I need to check developer site is going to developer database or not. Both databases have same data and same table names.
But i must work on developer database only how can I?
Generally you'd have an environment configuration file. If you're talking about ASP.NET then it would be the Web.config file. If you're indeed talking about classic ASP then it would probably be an included script with some constants.
If the databases are structurally identical (which they should be) then all you should need to change is the connection string. For classic ASP, you'd probably just store it in a variable:
Dim connString = "This is your connection string"
On the production server, the connection string would be set to your production database. On development machines, it would be set to a development database. (And so on for a test environment, etc.) All of the data access code would just use this connection string variable.
Even more to the point, this should not be the only thing that prevents a developer from using the production database. The DBA should set the permissions such that only the production application has only the access it needs to that database and others do not. Developers should never be able to accidentally modify the production database. So even if you did use the production connection string from your workstation, the database should simply deny you access.
Have two connection strings. Then create a constant variable which will act as your switch and pick the correct connection string:
Dim strCon
CONST DEVELOPMENT = true
if(DEVELOPMENT = true) then
strCon = "Development connection string"
else
strCon = "Live connection string"
end if
adoCon.open strCon
Then you can simply change the switch to true/false depending on which database to pick.
When you specify the database connection you know where you are pointing, so this should be straightforward. But it might be a good idea to use separate logins on dev and production.
So the answer is that you should use the connectionstrings in the config files to get what you need: the "database =.." setting should be set correctly and your problem is aolvedsolved To get extra certainty use different logins, which is recommendable in any case.
you can also use server tracing to monitor activity, but it is not easy on a multi user database and is only a diagnostics tool, not a cure.
I have a reportviewer (Microsoft.ReportViewer.WebForms) control on my page. All my reports use one data source. I want to be able to let my reports run on a different database when started from my UAT enviroment. So the location of the reports is the same, but the data comes from a different db. I cannot seem to find how this is done, is it even possible?
EDIT: They are server reports on SQL Server . I know you can set the dataset programmaticaly but I just want the reports to point to a different db and leave the rest of the report intact.
2005
TIA,
John
Did you want to pass a full connection string to the report as a parameter? You can do it but sometimes SSRS gets funny and make sure you delete the report off the server before you deploy a new copy when doing this...
1. Make a parameter - let's call ours connectionStr. Make it not null, not blank, single select and text as the data type. Eventually, you will want to hide this parameter but for testing please leave it visible.
2. So the value you will be using as the connection string... (for testing I set this as the default for the parameter, with nothing put under the available values section) Data Source=MySQLServerName;Initial Catalog=MyDatabaseName;Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True
3. You need an unattended execution account on your report server or you get this: unattended execution account is not specified. (rsInvalidDataSourceCredentialSetting). http://msdn.microsoft.com/en-us/library/ms156302.aspx I can't provide more details because my boss had to do this part for me.
4. Under your datasource properties in SSRS... check Embedded Connection, select the type (mine is just a normal MS SQL Server), for the connection string, open the expression box and put: =Parameters!connectionStr.value and then click credentials and make sure the last option for no credentials is selected.
5. Your datasets for that datasource will no longer be happy when you try to edit them in design view but you can switch the datasource connection properties back to how they were, not using the parameter based connection string, for editing them.
My reports are on different servers, with different instances of the Report Server, too. On some servers, they need to get their data from various databases depending on whatever, stuff. This way, with the connection string as a parameter, I can use the same reports everywhere and just deploy them to the different servers. If you are having to pass this connection string around your app or to a report viewer, I suggest using encryption.
Like I said... SSRS get's funny when you start doing this, though. Your reports should always work in preview mode after doing this, if they don't even when provided with the correct connection strings, then you have an issue that won't be solved by just deploying to the server. Trouble shooting problems with this once they are on the server but not working include checking permissions, making sure the report receives the correct connection string and making all your stored procedures and functions within the SQL database are all the same.
If you want to just pass the database name and everything else is the same (server name, username, password) then just set the connection string parameter equal to your database name and for the datasource expression value use
="Data Source=MySQLServerName;Initial Catalog=" + Parameters!connectionString.value + ";Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True"
I needed to pass the whole thing in, and you can play around with the credential settings - you might be able to save the server username/password info in there for each report so that the unattended execution account is not needed.
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?