I'm working on a Mavericks machine running a Windows 8.1 VM, trying to install an Oracle Database 12c. The installation runs fine up until it gets to the Database Configuration Assistant portion, where it immediately gives me the error mentioned above, "ORA-12560: TNS:protocol adapter error".
The database installer gives the option to skip a step, so I've tried doing so, and the database installation continues and completes. After it is completed, the Database Configuration Assistant is installed as an application. Running this application gives the same error immediately after setting some of the basic information (like database name, password, etc.).
I'm more or less brand new to Oracle databases, and I have no clue as to what this error might mean, or how to fix it. Does anybody have any idea as to why this error is appearing? I'm eager to provide any more information if it's needed, and would greatly appreciate any ideas or tips.
Thanks!
It seems to me that your oracle database is not up and running, this is a common issue for some first time users, what you need is to setup your database before anything else.
Try going to Control Panel, then Administrative Tools, then Services. Restart both OracleXETNSListener and the OracleServiceXE.
Or just go to start Start >> Run >> type "services.msc"
search for OracleXETNSListener and OracleServiceXE, right click then hit Start.
Related
I have designed a SSIS project and deployed it to SQL server and also created the job to run on daily basis but its giving me this error when executing this as job (doesnt give any error within VS):
There is this CLSid in this error message but there is no application associated to it in
--> Component Services -> Computers -> My Computer -> DCOM Config
But this CLSid is registered inside registry editor
About this particular task on which this error is occurring: This is a script task which is modifying and deleting the un-wanted rows from the excel file in which I am trying to write SQL table data.
Script task code looks like this:
I have been working for hours now trying to fix this problem but no success. Kindly guide me how can I fix this issue. If any other information is required related to this project, please let me know....
Doing Excel automation in a SQL Server agent job is totally unsupported and probably won't work.
To have even a ghost of a chance of making this work you'll need to run a real desktop session on the server and automate Excel in that. Excel expects a real user to be logged in with a full profile. And Excel has failure conditions where it displays a popup window, which you'll need to be able to access via remote desktop.
You can read and write Excel files on a server with the OpenXML SDK, without actually having to run Excel. There's also a wrapper library called ClosedXML which you may find easier to use than using OpenXML directly.
tl;dr;
You need to install Office (Excel) on the server AND ensure that you install it in a manner that mirrors the SQL Agent's expected bit-edness. Default for Agent is going to be 64bit, default for Office is still 32 :(
Error guessing
You have a script task that uses the Office interop libraries to delete some rows (2 through 11?) out of a spreadsheet.
You have Office installed on your machine and therefore you have the libraries installed. Excel still has COM based "stuff" in it, thus the interop and errors shrieking about the CLSid, registry, etc but that's likely just secondary errors because there is no base "application is not installed" exception to be thrown.
If Office is installed, then ensure your agent execution model matches the version of Office. If 32 bit Excel is already installed, don't potentially break everyone else's stuff by uninstalling and reinstalling as 64 bit, just got the Advanced section of the SQL Agent Job Step and check the 32bit box.
Once all that's done, then if you're still getting errors but new ones, then the existing comments mentioning permissions may come into play - it depends on where the Excel document actually exists (on the computer where SQL agent can access vs on the computer where it cannot vs networked drive)
Good luck in not finding people on the sanctions lists.
I am trying to query a remote database that I am connected to, however am having issues 'connecting' to the database with the Query Tool. The Query Tool opens, however the 'plug' icon stays red and doesn't seem to connect to the database (see picture below).
I'm not sure if that is the best way to describe it, however hopefully attached picture makes sense.
Is there a reason that this is occurring? I have left it to load overnight, etc. in case it is just waiting to connect with remote database but it still does not connect.
Thanks in advance
I had the same problem for months. But I found that the issue would be resolved when we download and install pgAdmin 4 v4.2 .If a VPN is needed to connect to your remote database, makes sure that it works fine in your computer.
The download link is:
https://www.pgadmin.org/download/
We had a similar problem with 3.x. In our case, upgrading to 4.4 did not solve the problem until we restarted the computer (MacOSX); although we had stopped the local server before upgrading.
An attempted deployment from (localhost) to (remote server) yielded the Error 27123 which, appears to be a credentials-related issue. After spending several hours the resolution appears to be one of assigning local-to-the-remote server Windows credentials that are used to launch DTEexec.exe. I am using VS2012 Ultimate locally with SQL Server 2014 Developer version and remote SQL version 2012 SP1. However, my attempts have failed so far.
I would VERY much like to be able to deploy to the remote server inside of VS2012, including creating folders, etc but am still at a loss as to the missing piece needed.
We do not have Active Directory set up as the remote is on the Amazon S3 cloud bit other than that is pretty much a plain vanilla setup. I also noted some folks suggested a Kerberos-based response but before I ask our network guru to proceed I'd like at least to get confirmation.
I AM able to manually FTP, install and run packages when remoted in but that stinks for my contractor who I would also like to be able to have me out of his way. s
All found online materials have not yet yielded the one last piece. I suspect my ignorance rather than the lack of a real solution and would appreciate any guidance.
Thanks in advance.
I have followed the instructions here.
To cut a long story short, I just cannot connect to:
https://machine/site/virtual directory/replisapi.dll?diag
I get:
HTTP Error 500.0 - Internal Server Error
Module IsapiModule
Notification ExecuteRequestHandler
Handler ISAPI-dll
Error Code 0x800700c1
Requested URL https://machine:443/site/virtual directory/replisapi.dll
Physical Path C:\inetpub\SQLReplication\replisapi.dll
Logon Method Basic
Logon User machine\user
When browsing to the DLL it does ask for my username and password then shows this error.
We're using a self signed certificate as this is just for testing.
I'm not really a server person so don't know what is going on? There's nothing in the event logs.
Does anyone have any bright ideas of things I could try?
P.S.
I also ran the wizard through SQL 2008 R2 which said it was successful (the wizard only works with IIS6) could there be a conflict between IIS6 and 7 now I have tried to set it up on both?
Ok, this was me being dumb.
After I retraced my steps backwards and unregistered replisapi.dll and moved into a backup directory.
I then removed my module mappings from IIS7.
I then ran the SQL wizard again, which copied replisapi.dll back to the directory.
I noticed it was a different size to the one I was using.
This was because I had got it from "Program Files" but being a 64bit machine the wizard got it from "Program Files(x86)" and now it works.
How simple yet frustrating!
I had to install the 32bit version of the DLL for this to work
I solved this (IIS8 and sql server 2008 x64) by entering ApplicationPool advanced settings and changing "Enable 32-bit Applications" to "True".
Hope this helps. This topic (web sync) is really bad documented
Vista just finished one of its many updates. After restarting my computer I try connecting to SqlServer2008 instance with Sql Server Management Studio and I get this error:
Error connecting to '...\MSSQLSERVER2008'.
Additional information:
Login failed for user '...'. Reason: Server is in script upgrade mode. Only administrator can connect at this time. (Microsoft SQL Server, Error: 18401).
Pressing help gets me to an internet page saying there's no additional information.
Thx Vista & Updates. Anyone an idea because on the internet I can't find anything about this issue.
It appears This Guy was having the same problems as you and his only suggestion was to wait a few minutes before trying to log in again.
I have yet to see any type of Microsoft documentation about this, nor have I seen any forum posts which came to any sort of resolution concerning the same problem.
Check your event viewer. I had the same problem and found that (in my case) it was looking for a directory that didn't exist to perform an upgrade script. NO hint that there was any sort of problem in the dialog, but the event viewer showed clearly what the problem was.
jim
I had the same problem. Waiting until update was done did not help. Solution was, (after checking Windows eventlog) to set the folder rights. SQL-Express had no rights on the database folder, why ever. Something has mixed up the rights during the upgrade from WinXP to Win 7. That was it.
Adding a comment to this page since this is the top Google result for "script upgrade mode". It seems that a number of things can cause a SQL Server DB to go into this mode. In our shop we've run into these two cases in the past months:
Log shipping - Can't recall at what point of the process exactly the DB went into this mode, iirc it was when bringing it back up. The solution was just to wait it out.
Hard drive full - The DB went into this mode when it ran out of space. We're currently clearing up the drive, will come back with an update if waking it up turns out to be challenging.
Update: After freeing up disk space, it was a simple matter of setting the DB "Offline" and then "Online" to bring it back up.
We had the same issue, but needed to know what was going on in the background.
The db's were put into recovery mode, hence they had to recover. To assist we went to the SQL Server error log located where the system files (normally master, model, msdb...) are located, but under the log folder. In the ERRORLOG, we did a find on the word recovery and could watch the db's percentage recovered. Everything recovered normally, but it was much longer than expected.
The Reason for this is that the system reboot happens with important\necesssary softwares loaded and does all other operation later so that the booting happens faster.
Here in your case, the sql booting is happening as the start of SQL is not needed for system to start. I hope you are aware of DAC account(Dedicated Administrator Connection, Link) who has seperate connectivity and has ability to resolve issues even the whole SQL server is not responing. The SQL server is asking you either to wait or open the SQL with DAC account and stop the SQL update.
Solutions:
1) Wait until backround update completes
2) Open SQL using DAC account and kill all running processes