Box was corrupt and was cleaned up and operational. Now, SQL Server will not connect to my db. I checked services and found that mssqlserver, SQL Server agents won't start. Gives error
Cannot connect to local server
They are set to automatically start, but manually starting gives the same error.
I cleaned his box with this recipe that I use successfully on dozens of computers. All other software is running fine. His box also had a failing disk so I xxcloned (XXClone.com) his disk to a fresh new disk. I believe the cleaning is an unrelated issue, but whatever it takes to fix it we are happy to try. I know many people with this SQL Server issue, and over the years have fixed it a few ways, but I am tight on time, so I suggested he get help here.
THOROUGH BADDY CLEAN. Clean a Windows Machine without Formatting it or losing Data
STEP 1
If Ransomware or some baddy is taking over our MBR or Partition so you cannot escape it, and cannot run safe mode, the ICE Ransomware being one of many examples.....
http://www.bleepingcomputer.com/virus-removal/remove-ice-cyber-crime-center-ransomware
use a empty USB stick and HitManPro (the free version will remove)
http://www.surfright.nl/en/hitmanpro/
STEP 2
Reboot in Safe mode with networking by rebooting and holding down F8 key. None of this will permanently fix your computer unless you are in SAFE MODE w/ NETWORKING
Download RKill and run it
Download ComboFix from BleepingComputer.org and run it
Download SmitFraudFix and run it
Download AntiMalwareBytes to catch everything those did not
I can clean any machine no matter how badly infected with these tools in safe mode. Will keep recurring if attempted in Normal Mode. Safe mode is the key.
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.
We're building a new installer for our software, which consists of installing SQL Server 2014 Express. One thing about SQL Server is that it does not allow you to continue installing if your computer's pending a restart. We run it in silent mode, so it essentially just fails to install SQL Server. More specifically, when the computer's pending restart due to Windows updates.
I found this question, but did not help. Then I found this article, wrote a function, and actually answered on that question.
Then I tested it on a few other systems. It turns out, this function also returns true on a system which is pending any Windows updates, but not necessarily a restart. In fact, this system hasn't had an update since January... But the SQL Server install itself doesn't complain. So one or more of the checks in this function are not necessary.
I disabled two of those checks:
SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending
Software\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending
However it's still returning true on the system which SQL doesn't actually have a problem with.
Which of these checks are necessary for us to test to equate to SQL Server's checks, so that we can ensure the SQL installation won't fail later on in the install process?
It seems the question on how to connect to oracle database from UFT/VBscript is asked on multiple forums. In most places, there are answers in bits and pieces, without any one detailed answer that helps user get this information.
I spent close to 6 days to get this working and thus I feel its worth to share all the detailed steps here. The main reason I found this for going wrong is a wrong combination of one or more of below:
Using the wrong driver.
Using the wrong connection string.
Using the wrong terminal to test the code (i.e. 64 bit to test working for a 32 bit UFT)
When any one of the above is wrong, we get a range of errors depending on which driver, connection string and terminal we are using. I encountered:
Provider cannot be found. It may not be properly installed (when using Microsoft ODBC for Oracle)
The 'OraOLEDB.Oracle.1' provider is not registered on the local machine (when tried using oraOLEDB driver)
Catastrophic failure. (when running a working script on 64-bit terminal)
Hope below answer will give you a step by step answer with references, and code examnples to try out your code and get this up and running for you.
It took me 5 days to get this correctly working and although there is information available on internet, its all scattered and leads to multiple directions, which can be very time consuming and frustrating. So to save you from this frustration and also since test data is very crucial for setting up any meaningful test framework, this section is dedicated to making this properly set up for you. Hopefully, you will not have to face the same frustration that I went through in dealing with this!
To make oracle database connection work in UFT, download a 32-bit driver for your oracle database. To do this:
Go to this page (if your database is 12c - if another database, go to that page), https://www.oracle.com/database/technologies/oracle12c-windows-downloads.html
Scroll down and look for "Oracle Database 12c Release 2 Client (12.2.0.1.0) for Microsoft Windows (32-bit)" - If you are working on oracle 12C
Download the zip file "win32_12201_client.zip"
Extract the file and run "setup.exe" from the folder : Downloads\win32_12201_client\client32
While selecting "What type of installation do you want",
select -> Administrator (1.5GB)
Use windows built in account (3rd option)
Keep default locations for
oracle base -> C:\app\client\yourUserID (no space in between allowed)
software location -> C:\app\client\yourUserID\product\12.2.0\client_2
Save response file for your future reference
Install the product
To test if everything went okay or not, open the ODBC connection for 32 bit
Check in the driver's section, if a driver with name "Oracle in OraClient12Home1_32bit" is installed or not.
Now you can run the vbscript for testing database connection by running it in 32-bit command line mode. (Running it in a terminal on 64 bit machine would give you all sort of errors). To do this on windows,
Type %windir%\SysWoW64\cmd.exe in Start Search box.
Change directory to your script location (say cd c:\Users\yourUserID\UFT\Rusty\FunctionLibrary) - If the script is in dir FunctionLibrary
Now you can run the script by writing cscript in front of it -> cscript database-functions.vbs
You should see values popped up from test script.
Connection string format:
https://www.connectionstrings.com/oracle-in-oraclient11g_home1/ (use standard format from here)
Dim connString: connString = "DRIVER={Oracle in OraClient12Home1_32bit};DBQ=yourHostURL:portNr/DBname;Trusted_Connection=Yes;UID=MyUser;Password=myPassword"
Ex (with dummy values): connString = "DRIVER={Oracle in OraClient12Home1_32bit};DBQ=ab12.mycompany.com:1521/ORAB;Trusted_Connection=Yes;UID=pramod;Password=myPassword"
A script that you can use to test this connection is here.
https://github.com/PramodKumarYadav/Rusty/blob/master/FunctionLibrary/test-data-functions.vbs
Or here: https://hoopercharles.wordpress.com/2009/12/12/simple-vbs-script-to-retrieve-data-from-oracle/
Change the connection string to as mentioned above.
Hope this helps and you can save a lot of time and energy in using oracle connection itself to build tests, than setting this up itself.
I have installed a fresh instance of AX 2012 R3 on my system. When I try to start the service on my machine i get the following error:
Note: When I try to start the service through Local system it works. But I want to start it through the account NT Authority/Network Service. Any suggestions?
Another anomaly is that when i try to install DIXF it gives me the following error: "Verify that you have enough privileges to start the service"
It sounds like you've narrowed the issue down yourself. Do you need to have it running as the network service account? Run it as your user or another user with access to SQL.
I'd say that it's a permissions issue to SQL and/or file permissions on the machine the AOS resides on.
https://technet.microsoft.com/en-us/library/dd362055.aspx
Debugging a crashing AOS server is not a simple task.
As I see from your Event Log you are running build number 6.3.164.0 which is the RTM build of 2012 R3. Many hotfixes have been released since and there is a good chance your problem goes away with just installing the latest kernel build. See Overview of Microsoft Dynamics AX build numbers for links to more recent builds.
Running a newer kernel with an older application build is supported, but since it's a fresh instance I'd update the application too.
If you would have a go at debugging this yourself you could try to get a memory dump to analyze with windbg. Refer to this article So your AOS crashed, is hanging, or you just want to see what it's doing .
Unfortunately my results with that approach have been mixed. Unfortunately we don't have access to all debugging symbols we need, and in this case, since it crashes immediately on startup I don't know what to expect.
Your third and last option is to open a support ticket with Microsoft and provide them with memory dumps, but their suggestion will be to update to a more recent build anyway.
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