i've a simple question.
Is it possible to use another database name as the readme says it have to be called "DotNetNuke" ?
manually create SQL Server database named "DotNetNuke" ( using Enterprise Manager or your tool of choice )
i've a webhost which have different database names.
thanks
Yes, you can use any database name that you would like. During the installation process, you provide your database name.
You can also manually edit the connection string in the web.config file. By doing this the Auto install option will still be available.
Related
I installed Oracle 11g, with ad instance called orcl.
And I want to create another instance, called for example orcl1.
How could I do that? Do I nead to re-install another database like I did the first time?
You need either to use :
DBCA : recommended because easier. See example (this assumes that Oracle executables have already been installed).
or
CREATE DATABASE SQL statement with SQL*Plus: more complex.
SQL lite created by using the following code
Database db = Database.openOrCreate("test.db");
Its creates the database, after that we created tables on this database. We need to know where is this test.db file stored?.
Note: we are using Net Beans IDE on windows 10 system for our development.
Thanks in advance
This is discussed in the SQL section. You need to use getDatabasePath before opening the database to replace the file with a premade file which I assume is the use case you are aiming at.
We can get the .db file from the path "C:\Users\Admin.cn1\database".
I installed db2 client in my system for personal use. I am not able to understand from where to create the database so that i can create tables on that db and play around with sql queries as of now.
This is totally related to my personal use and learning purpose.
Please inform how to create a dummy database and play around with it with db2 client?
Regards,
Are you on Windows? Are you using DB2 Express-C? I'm assuming you are, since you say this is for personal work.
After you have the DB2 binaries installed, you should have been prompted with the "DB2 First Steps" application, where you could have the application go through a GUI to create the database for you. If you missed it, you should be able to find it in your start menu with Start -> Programs -> IBM DB2 -> DB2COPY1 (Default) -> Set-up Tools -> First Steps.
If you prefer the command line, you can use the following:
First, determine if your installation created a default instance (on Windows, this will be called DB2) by using the db2ilist command. In the DB2 Command Window, if you're not on the instance you want to create a database in, you can switch with the following command:
set db2instance=DB2
Be sure to not include spaces around the equal sign.
Now, in order to create a database in the current instance, you use this command:
db2 create database mydatbase
For further reading, IBM has produced a Getting Started ebook, and I would highly recommend you check it out!
The DB2 client is just that - a client only. It does not include the database engine.
To create a database you have to install the server. The server includes the client portions.
I've faced a bit strange problem. There is a site client would like to duplicate on another domain name. Site is built on ASP(yes, old v1 ASP :( ) with SQLServer. Problem is that all the database operations, including connection information is compiled into a DLL library.
Is there a way to some how intercept, override or workaround this?
Platform:
Windows 2000 Server
SQLServer 7
ASP v1 (VisualBasic)
What a nightmare...
If you have control over the new database server, and the connection string references the database server by name, you could add a line in the hosts file which points the name of the old server to a new ip address. Then you still have to create a user with the same password on the new database server.
Yes! However, your new database name MUST be smaller or equal to the length of your old one. Simply open up the vb6 .dll in any Hex Editor and search and replace. Make SURE you do not change the length of the DLL or shift any bytes around.
Failing that, add a hosts entry to windows to redirect the connection.
Could it be that the application uses a DSN definition for the connection?
In Control Panel -> Administrative Tools open ODBC Data Source Administrator. Have a look at the System DSN tab. Does there seem to be anything listed there that is related to the application?
Before you hack your DNS or rename the server, be aware that the SQL Server client supports aliases specifically for this scenario: How to: Create a Server Alias for Use by a Client.
The SQL 2000 tool for configuring an alias is the Client Network Utility.
Do you have any configuration options at all from asp? Even dbname or the such? If so you might be able to use two separate servers for IIS and use a single db server. I'm afraid you might need to find the source or the guy who wrote it.
If you could figure out the connection string or DNS you might be able to do something.
You could write your own passthrough ODBC provider.
I used to have a dts that had a sql server authentication connection. Basically, the userid password is stored in the package itself. Now, when I go to SSIS, the password is not getting stored to the package. I saw SSIS Connection Manager passwords when I googled the problem, but no one seems to have given a good resolution.
You can store the password in the configuration string by going to properties and adding password=yourpassword, but it's very important to put a space after the ; on the line before password and after the ; on the password line, as shown below:
Data Source=50.21.65.225;User ID=vc_ssis;
password=D#mc317Feo;
Initial Catalog=Sales;
Provider=SQLNCLI10.1;
Persist Security Info=True;Auto Translate=False;
Application Name=SSIS-PKG_CustomerData-{2A666833-6095-4486-C04F-350CBCA5C49E}IDM11.Sales.dev;
That answer points to this article: http://support.microsoft.com/kb/918760
Here are the proposed solutions - have you evaluated them?
Method 1: Use a SQL Server Agent proxy account
Create a SQL Server Agent proxy account. This proxy account must use a credential that lets SQL Server Agent run the job as the account that created the package or as an account that has the required permissions.
This method works to decrypt secrets and satisfies the key requirements by user. However, this method may have limited success because the SSIS package user keys involve the current user and the current computer. Therefore, if you move the package to another computer, this method may still fail, even if the job step uses the correct proxy account.
Back to the top
Method 2: Set the SSIS Package ProtectionLevel property to ServerStorage
Change the SSIS Package ProtectionLevel property to ServerStorage. This setting stores the package in a SQL Server database and allows access control through SQL Server database roles.
Back to the top
Method 3: Set the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword
Change the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword. This setting uses a password for encryption. You can then modify the SQL Server Agent job step command line to include this password.
Method 4: Use SSIS Package configuration files
Use SSIS Package configuration files to store sensitive information, and then store these configuration files in a secured folder. You can then change the ProtectionLevel property to DontSaveSensitive so that the package is not encrypted and does not try to save secrets to the package. When you run the SSIS package, the required information is loaded from the configuration file. Make sure that the configuration files are adequately protected if they contain sensitive information.
Method 5: Create a package template
For a long-term resolution, create a package template that uses a protection level that differs from the default setting. This problem will not occur in future packages.
I use a variable to store the entire connection string and pass it into the ConnectionString expression. This overwrites all settings for the connection and allows you store the password.
The designed behavior in SSIS is to prevent storing passwords in a package, because it's bad practice/not safe to do so.
Instead, either use Windows auth, so you don't store secrets in packages or config files, or, if that's really impossible in your environment (maybe you have no Windows domain, for example) then you have to use a workaround as described in http://support.microsoft.com/kb/918760 (Sam's correct, just read further in that article). The simplest answer is a config file to go with the package, but then you have to worry that the config file is stored securely so someone can't just read it and take the credentials.
Please check the configuration file in the project, set ID and password there, so that you execute the package
It happened with me as well and fixed in following way:
Created expression based connection string and saved password in a variable and used it.
Try storing the connection string along with the password in a variable and assign the variable in the connection string using expression.I also faced the same issue and I solved like dis.
Check the text contents of the connection manager file itself, the password field might be configured in the Project.params file, in which case entering the password into the connection manager window will cause it to not save.
Here is a simpler option that works when I encounter this.
After you create the connection, select the connection and open the Properties. In the Expressions category find Password. Re-enter the password and hit Enter. It will now be saved to the connection.
There is easy way of doing this. I don't know why people are giving complicated answers.
Double click SSIS package. Then go to connection manager, select DestinationConnectionOLDB and then add password next to login field.
Example: Data Source=SysproDB1;User ID=test;password=test;Initial Catalog=ASBuiltDW;Provider=SQLNCLI11;Auto Translate=false;
Do same for SourceConnectionOLDB.