I was trying to set this parameter and was having difficulty with it.
In the Plesk database section i had the database i wanted to use. First i had to make a dump of the database i was using locally with my aspnet core project. I used SQL Management studio to access the database on the SqlExpress Server, that is the one that is installed with visual studio and the one that is used by default when creating a application with user login template. The sqlExpress server name is (localdb)\MSSQLLocalDB.
Still on the SqlManagment studio, i selected the database, right-mouse click, Tasks, dump database.
On the plesk management area, on the database sections, i made a import of that file for the specific database i wanted to use. Then clicked the check button and it was ok.
Then the hardest part was to figure out what connection string to use, and even, what is the name of the server?
Solution in answer.
On the Plesk database area, on the specific database there is a "Connection info" which gives us the following info:
Host ------------------- .\MSSQLSERVER2019
Database name --- myspecificdb_
User name ---------- myusername
Password ----------- myPassword123+
And the connection string we should have on our appsettings.json is...
"DefaultConnection": "Data Source='.\MSSQLSERVER2019';User ID=myusername;Password=myPassword123+;"
Now, why it works without specifiyng the database name is a mistery to me. If anyone knows please feel free to explain.
So the correct way is:
"DefaultConnection": "Data Source='.\MSSQLSERVER2019';User ID=myusername;Password=myPassword123+;Database=myspecificdb_;"
I can connect oracle through command prompt but I can't connect it oracle home page through Home page, recently it's showing error, I used always from localhost. Suddenly I can't enter through my Oracle 10g home page?
1.I do TRIED to SET CHROME SETTING
2.PROXY SERVER FROM MY PC ALSO
3.I TRIED TO OPEN IT FROM FIREFOX ALSO , IT ALSO SHOWING ERROR
here the error
When you say "oracle home page", it looks like you're trying to connect to a local instance of Oracle Application Express (maybe 4.2, since you're using Oracle Database 10g).
Probably your Oracle HTTP Server Windows service has stopped. There are two ways you could try to fix this:
A) Open Windows Settings, type "services", and open the Services control panel. Scroll down to the names starting with "Oracle", right-click on the HTTP Server one, and click "start".
B) Follow the instructions in the docs:
cd %ORACLE_HOME%\opmn\bin
opmnctl verbose startproc ias-component=HTTP_Server
If you're still having problems, you might have to look at the HTTP server logs - I think for 10g they were stored in ORACLE_HOME\Apache\Apache\logs\, but I'm really not sure.
I had a new machine which windows crashed and I had to do a Windows reset which reinstalled Windows. Afterwards I deleted the old app user accounts in the C:\Users folder since the reinstall didn't delete it, these included SQL Server MSSQLServer and .net accounts because I was going to install all the apps from scratch I decided to clear it up and delete it.
I then ran SQL Server 2014 SP1 setup selecting database engine, client connectivity and Management Studio on default instance MSSQLServer
using mixed mode authentication and added my own sa password and my current windows user.
At the end of my installation I notice the installer takes a very long time at the following step
SqlEngineDBStartConfigAction_install_configrc_Cpu64
I then get an error
The following error occurred:
Could not find the Database Engine startup handle.
Logs
Feature: Database Engine Services
Status: Failed: see logs for details
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, uninstall this feature, and then run the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A0019
Error description: Could not find the Database Engine startup handle.
Error help link: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=12.0.4100.1&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4025&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4025
I open SQL Server configuration manager Services and noticed my MSSQLServer doesn't start up because it runs as NT Service\MSSQLSERVER user. I change that to local system account and start the service and the service runs.
However when I open SQL Server Management Studio and try to connect to the database engine I can't connect with neither my windows user I added during the SQL Server setup nor the sa user with password I specified.
Cannot connect to PCName. Login failed for user PCName\User. Microsoft SQL Server Error 18456
When I uninstall SQL Server and reinstall it I get the same issue. Even when I delete the program files directory C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER
How do I get it to work?
Why does a new SQL Server 2014 SP1 installation not create the MSSQLServer user?
How to I create the MSSQLServer user manually and what permissions and groups do I assign to it?
I tried everything to resolve it. Delete all the SQL Server folders. Remove registry entries as mentioned in other stackoverlow answers. Installed SQL Server 2014 SP1 again and the problem still occurs.
Even when I installed SQL Server 2012 SP1 on the default instance I would still get the error.
The only workaround I could get it to work was to install SQL Server as a separate instance and not the default instance.
This made me thinking if the issue is only related to the default instance.
I looked at my C:\Users folder and the default instance MSSQL user folder was not there meaning the installer never created it. The problem must have occurred that I previously deleted the User folder to clean up the machine where I should have deleted the windows users from Control Panel Admin Tools instead.
Solution: Use regedit.exe
The problem entry should be the corresponding S Folder in.
HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft -Windows NT -CurrentVersion -ProfileList
Delete this user
Reinstall and verify in the C:\Users if the MSSQL user gets created.
I tried to be safe and deleted all references to the MSSQL user in the registry user after uninstalling all SQL Server references in Add/Remove Programs and clearing up the Program Files folders the one registry item is probably the cause.
This solution helped me to fix the issue.
I had deleted MSSQLServer and SQLAgent account while cleanup of SQLServer2016, but then MSSQLServer 2016 installer wasn't getting re-installed, reason being it could not create the service account, and my application is limited to support "only default SQL instance"
I have followed this and deleted the REG entries and this helped me to reinstall SQL Server smoothly.
Thank you so much .
Solution: Use regedit.exe
The problem entry should be the corresponding S Folder in.
HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft -Windows NT -CurrentVersion -ProfileList
I am trying to run openrowset from MS SQL Server on an Oracle server.
When i execute the following command:
select * from
OPENROWSET('OraOLEDB.Oracle','srv';'user';'pass',
'select * from table')
the following error occurs
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "OraOLEDB.Oracle" for linked server "(null)".
Can anyone tell me how I can use openrowset with OraOLEDB.Oracle?
I am using 64 bit version of MS SQL Server and Oracle OLEDB driver.
Edit
I have tried this on two machines running Windows 7 x64 & Windows Server 2008 x64 with MS SQL Server 2008 x64. Both showed the same error message.
In SQL Server Enterprise Manager, open \Server Objects\Linked Servers\Providers, right click on the OraOLEDB.Oracle provider, select properties and check the "Allow inprocess" option. Recreate your linked server and test again.
You can also execute the following query if you don't have access to SQL Server Management Studio :
EXEC master.dbo.sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
Ran into this issue where the linked server would work for users who were local admins on the server, but not for anyone else. After many hours of messing around, I managed to fix the problem using the following steps:
Run (CTRL + R) “dcomcnfg”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
Copy the “Application ID” on the properties page.
Close out of “dcomcnfg”.
Run “regedit”. Navigate to “HKEY_CLASSES_ROOT\AppID{???}” with the ??? representing the application ID you copied in step #3.
Right click the “{???}” folder and select “Permissions”
Add the local administrators group to the permissions, grant them full control.
Close out of “regedit”.
Reboot the server.
Run “dcomconfig”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
On the “Security” tab, select “Customize” under “Launch and Activation Permissions”, then click the “Edit” button.
Add “Authenticated Users” and grant them all 4 launch and activation permissions.
Close out of “dcomcnfg”.
Find the Oracle install root directory. “E:\Oracle” in my case.
Edit the security properties of the Oracle root directory. Add “Authenticated Users” and grant them “Read & Execute”, “List folder contents” and “Read” permissions. Apply the new permissions.
Click the “Advanced Permissions” button, then click “Change Permissions”. Select “Replace all child object permissions with inheritable permissions from this object”. Apply the new permissions.
Find the “OraOLEDB.Oracle” provider in SQL Server. Make sure the “Allow Inprocess” parameter is checked.
Reboot the server.
When connecting to SQL Server with Windows Authentication (as opposed to a local SQL Server account), attempting to use a linked server may result in the error message:
Cannot create an instance of OLE DB provider "(OLEDB provider name)"...
The most direct answer to this problem is provided by Microsoft KB 2647989, because "Security settings for the MSDAINITIALIZE DCOM class are incorrect."
The solution is to fix the security settings for MSDAINITIALIZE. In Windows Vista and later, the class is owned by TrustedInstaller, so the ownership of MSDAINITIALIZE must be changed before the security can be adjusted. The KB above has detailed instructions for doing so.
This MSDN blog post describes the reason:
MSDAINITIALIZE is a COM class that is provided by OLE DB. This class can parse OLE DB connection strings and load/initialize the provider based on property values in the connection string. MSDAINITILIAZE is initiated by users connected to SQL Server. If Windows Authentication is used to connect to SQL Server, then the provider is initialized under the logged in user account. If the logged in user is a SQL login, then provider is initialized under SQL Server service account. Based on the type of login used, permissions on MSDAINITIALIZE have to be provided accordingly.
The issue dates back at least to SQL Server 2000; KB 280106 from Microsoft describes the error (see "Message 3") and has the suggested fix of setting the In Process flag for the OLEDB provider.
While setting In Process can solve the immediate problem, it may not be what you want. According to Microsoft,
Instantiating the provider outside the SQL Server process protects the SQL Server process
from errors in the provider. When the provider is instantiated outside the SQL Server process,
updates or inserts referencing long columns (text, ntext, or image) are not allowed.
-- Linked Server Properties doc for SQL Server 2008 R2.
The better answer is to go with the Microsoft guidance and adjust the MSDAINITIALIZE security.
For error 7302 in particular, I discovered, in my registry, when looking for OraOLEDB.Oracle that the InprocServer32 location was wrong.
If that's the case, or you can't find that string in the registry, then you'll have to install or re-register the component.
I had to delete the key from the GUID level, and then find the ProgID (OraOLEDB.Oracle) key, and delete that too. (The ProgID links to the CLSID as a pair).
Then I re-registered OraOLEDB.Oracle by calling regsvr32.exe on ORAOLEDB*.dll.
Just re-registering alone didn't solve the problem, I had to delete the registry keys to make it point to the correct location. Alternatively, hack the InprocServer32 location.
Now I have error 7308, about single threaded apartments; rolling on!
Received this same error on SQL Server 2017 trying to link to Oracle 12c. We were able to use Oracle's SQL Developer to connect to the source database, but the linked server kept throwing the 7302 error.
In the end, we stopped all SQL Services, then re-installed the ODAC components. Started the SQL Services back up and voila!
Aside from other great responses, I just had to give NTFS permissions to the Oracle installation folder.
(I gave read access)
Similar situation for following configuration:
Windows Server 2012 R2 Standard
MS SQL server 2008 (tested also SQL 2012)
Oracle 10g client (OracleDB v8.1.7)
MSDAORA provider
Error ID: 7302
My solution:
Install 32bit MS SQL Server (64bit MSDAORA doesn't exist)
Install 32bit Oracle 10g 10.2.0.5 patch (set W7 compatibility on setup.exe)
Restart SQL services
Check Allow in process in MSDAORA provider
Test linked oracle server connection
Just enable option "Allow in process" on the properties of the OraOLEDB.oracle provider as below
[open server objects > Linked Severs > providers] 1 [right click on
OraOLEDB.oracle > properties ] 2 then choose optaion "Allow in
process" and click ok
I have a database set up that is to gather planned vacation time that I need to put on sharepoint asap. It's completely done, except for that the application login is failing for anyone that tries to use it that does not have their corprate login (windows authentication) listed in the security logins folder.
The connection string is fine, as it works properly on my computer and another programmer's computer, but not on my boss's computer. I can also login to sql server using the application login that is listed in the connection string.
I'm using SQL Server Managment Studio 2008, the server is 2005.
Edit#1: Further research led to finding this page: http://sql-articles.com/articles/troubleshooting/troubleshooting-login-failed-error-18456/
And my error is state 11. It's listing a windows authentication in the error log even though I specified otherwise.
Edit#2: My Connection String is this:
Driver={SQL Server};Server=ServerName\ThingIdontUnderstand;Database=ReportingDevDB;Trusted_Connection=FALSE;uid=Derp;pwd=qwerty;
Edit#3: Solved! See comments on this post for answers since I can't answer my own questions yet.
You check for the version when you connect to the instance through SSMS it will show it beside the server name under Object Explorer. Or just use the query SELECT ##VERSION
I would suggest simply creating a corporate windows group and adding those individuals to it, and then simply add this group as a login to your instance of SQL Server.