I have a problem when I tried install SQL Server Express 2016 through config.ini
Preamble
remote server is Windows 2016 ENG with last patch
On my disk c:\temp I have the SQL setup files, and the sql_conf.ini file.
On the instance I have installed all modules and service needed by SQL.
If I open a rdp session on the server and run the command 'c:\temp\SQLEXPRADV_x64_ENU\SETUP.EXE
/configurationfile=c:\temp\sql_conf.ini' it's works withous any
problem.
the user that Ansible use to connect is named "ansible" and is on Administrators group.
The playbook is:
- name: 'Installo SQL Server Express 2016'
win_shell: 'c:\temp\SQLEXPRADV_x64_ENU\SETUP.EXE /configurationfile=c:\temp\sql_conf.ini'
args:
chdir: 'c:\temp'
Result is:
There was an error generating the XML document. Error result: -2068774911
I tried replace win_shell with the modules win_command and win_psexec but not have any change.
I also tried with directive become_method: runas but nothing change.
After many tries, I found this behavior:
If a login, only one time on remote server, via rdp with "ansible" user, (and then logoff) the palybook work without any problem!
I have found a workaround using win_dsl module (and not the sql_conf.ini file), but I would like understand why with the modules win_shell, win_command and win_psexec, not work.
Someone have any idea?
Related
At last, I used sqlserver often at 2005s. now just installed VS2017. and it seems MSSQLLocalDB 2016 connection name of instance is changed from .\SQLEXPRESS to something like: (localdb)\MSSQLLocalDB and it doesnt connects. and I checked the list services.msc and couldnt find any relevant name "sql".
is it removed in services ? or its not a service anymore maybe a standalone app ? (thanks)
and look! I dont ask why I cannot connect. Im asking the name of "SQL Server" in services.msc. is it now a standalone app ratherthan being a background server task?
it just doesnt exists anymore ? or am I missing something
it seems MSSQLLocalDB 2016 connection name of instance is changed from
.\SQLEXPRESS to something like: (localdb)\MSSQLLocalDB
These are just two differnt products.
LocalDB installation copies a minimal set of files necessary to start
the SQL Server Database Engine. Once LocalDB is installed, you can
initiate a connection using a special connection string. When
connecting, the necessary SQL Server infrastructure is automatically
created and started, enabling the application to use the database
without complex configuration tasks. Developer Tools can provide
developers with a SQL Server Database Engine that lets them write and
test Transact-SQL code without having to manage a full server instance
of SQL Server.
he cite is taken from here: SQL Server 2016 Express LocalDB
So SQL Server Express is a full server instance (and also win service) while Localdb is not.
You cant find SQL Server in services.msc
if you wish to configure the SQL SERVER you can just search in your computer an application named : "SQL SERVER 2016 Configuration Manager" - then you can for example turn off\on the SQL Server and etc .
(localdb)\MsSqlLocalDB does not run as a Windows/System Service, so you will not see it listed in Services.msc
As mentioned previously, MsSqlLocalDB is the 'developer edition' of SqlExpress and is normally run as an 'in-process' database server, not as a out-of-process service.
When your application runs, and it opens a connection to MsSqlLocalDB, the proces of Opening the DB connection will cause the MsSqlLocalDB engine to be instantiated within your current process, and then your application will be using it. When your application exits, MsSqlLocalDB will normally exit also.
You can run SqlExpress and MsSqlLocalDB at the same time. SqlExpress will normally be running as a Windows Service under the connection point '.\SqlExpress' and when your application runs it will instantiate '(localdb)\MsSqlLocalDB'
I am really tired, it's been 3 days that I can't open my SQL Server Management Studio. I got connection string error with number 87. Below screenshot show my problem:
And I use localhost\MSSQLSERVER with error 87 and Arash-PC (my machine name) with error number 2.
And I tried sqlcmd -U sa -S Arash-PC too
You need to check in your SQL Server Configuration Manager what services and instances you have installed. Go to Start Menu > All Programs > Microsoft SQL Server (version) > Configuration Tools and launch the appropriate Configuration Manager. You should see a screen something like this:
Find the SQL Server (.....) service(s), and make sure the service is started.
If you find a SQL Server (MSSQLSERVER) service started, then you have a (unnamed) default instance to which you can connect using
.
(local)
Arash-PC
You MUST NOT supply the MSSQLSERVER as the instance name!
If you find any other SQL Server (instance name) service started (e.g. SQL Server (SQLEXPRESS) in my screenshot), then the instance name (SQLEXPRESS) needs to be appended to the server name to connect to that instance:
.\SQLEXPRESS
(local)\SQLEXPRESS
Arash-PC\SQLEXPRESS
Make sure you are not running out of space on the drive where SQL is installed. Try rebooting as well.
Verify that the SQL Server (MSSQLSERVER) service is started. Click Start, click Administrative Tools, click Services, and scroll to SQL Server (MSSQLSERVER). If it is not started, right-click the service, select Properties, in Startup Type select Automatic, click Apply, click Start, and then click OK. Make sure service started. If service did not start - you need to analyze event log. Alternatively - try reinstalling/repairing SQL server.
Make sure you have no network problems - try temporary disabling any firewalls(including Windows Firewall) and antiviruses.
If service is started and firewalls disabled but still no luck - time to check SQL Server Configuration Manager settings. In detail it is described here and here. Shortly I would recommend first enable all protocols in both server and client sections. Reboot. Check it works. If that would not help - then try disabling everything apart from TCP/IP (both server and client sections). Reboot again.
If above does not help - try reinstalling SQL Server. Just make sure you have saved your databases 1st. To save them - stop sql server service, and copy your *.mdf and *.ldf (from SQL server Data folder) files to safe location. Later on you can attach them. If you are not sure where your SQL server Data folder located - just search for files with mdf extension.
Edit:
Successful telnet showing SQL server port is up looks this way:
Edit2:
Launch Event Viewer:
Click System, then Filter Current Log:
Setup filter as shown below:
Then look for SQL-related events:
Usually event text provides information why MSSQLSERVER service fails to start. If the text is unclear please google it for more details.
If your problem was the same as mine (or to anyone else whose attempting to connect to their MS SQL Server w/ a similar connection string), MSSQLSERVER is the default instance name when you set it up, if you don't provide an instance name. I omitted the MSSQLSERVER from the connection string and I was successfully able to connect.
With all respect to "Anton Kruglov" and "marc_s" , Unfortunately, my problem is not resolved . I had to change my windows and reinstall softwares . Now it works properly .
Here is the short version of the problem: I have a discrete DTSX file that works fine on our Production server, but doesn't on our new Dev server.
Symptom: When run from a SQL-Server job, the job starts and nothing at all happens, and it never finishes... it just hangs, using very little system resources.
Some info: For Prod, the packages were developed on SQL-Server 2012 and run on an NT 2008 server. The new Dev server is also SQL-Server 2012, but runs on an NT 2012 server (in case that matters). I have duplicated the folder/file structure exactly, including drive name. The package uses an external dtsConfig file, but as I said - the folder/file structure is identical.
The SSIS service, SQL-Server Agent, and my remote login are all the same, and is a member of the server Administrator group on the Dev box. If I copy the command line text from the SQL job and run it in a CMD window using dtexec.exe, the package executes correctly. The job owner is my login, and the "run as" is the SQL-Agent, which - as I mentioned - is the same login. Since everything in the package uses integrated security, everything should be running using the same login whether on the command line or via the SQL-Agent, which should eliminate any user permission/credentials issues.
I tried adding SSIS logging to the package, logging everything I could. When I run the package from the command line, I get a ton of messages in the log. When I run the package via the SQL job, there are no messages at all in the log - nothing.
Whatever is going on, it's not getting far enough into the SSIS package to generate a single log entry. It's just stopping but not exiting or throwing an error. FWIW - I have the same problem with every other package I've tried.
Any ideas are appreciated...
I found the cause of the problem. The MS-SQL Server service was using a different login than the SSIS server service and the NT Agent service (it was using a local service account).
Once I changed the MS-SQL Server login to match the others (and restarted the service), the job ran correctly.
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'm trying to set up a SQL Server 2012 LocalDB (RTM, x64) shared instance on my Windows 7 x64 machine and I can't seem to connect to the shared instance. I'm using an Administrator command prompt for all of the setup. Here's how I'm creating the instance:
sqllocaldb create MyInstance
Which yields the response:
LocalDB instance "MyInstance" created with version 11.0.
So far so good. Now I share the instance:
sqllocaldb share "MyInstance" "MySharedInstance"
Which results in:
Private LocalDB instance "MyInstance" shared with the shared name: "MySharedInstance".
Still looking good. At this point, I the info command yields:
.\MySharedInstance
MyInstance
v11.0
Connecting to the instance from the owner account (which is an admin) using both an admin or non-admin command prompt seems to work fine. Things come off the tracks, though, when I log in as a regular user (not a windows admin) and try to connect:
sqlcmd -S (localdb)\.\MySharedInstance
results in:
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Named Pipes Provider: Could not open a connection to SQL Server [2]. .
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Login timeout expired.
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..
Increasing the login timeout using the "-l" switch does not help. I can connect to the default v11.0 instance, which is not shared. The info command for the non-admin user yields the same as above except withouth "MyInstance" since it's a named instance owned by the admin user. The following command (which works for the admin user/instance owner):
sqllocaldb info ".\MySharedInstance"
also results in an error:
Windows API call "FileTimeToSystemTime" returned error code: -2147024809.
So the question is why can't my non-admin user connect to my shared instance? This seems to defeat the whole purpose of shared instances. And what's with the "sqllocaldb info" command throwing an error when I try to query about the shared instance?
ANOTHER EDIT
Cory, if you have previous versions of SQL Server installed (e.g. 2008), that is the version of sqlcmd you are using. In order to connect to LocalDb you need to be using the SQL Server 2012 version of sqlcmd. So your instructions to your users must ensure that they use the SQL Server 2012 version by running:
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd -S "(localdb)\.\InstanceName"
This worked for me. What I haven't verified is whether this path and version of sqlcmd is available to users who have only installed the sqllocaldb.msi. Sorry but I don't have any naked machines without SQL Server 2012 installed (or with only previous versions installed) to try this out thoroughly. But please let me know if explicitly calling the 110 version of sqlcmd does the trick.
I think you may also be able to instruct users to alter their system variables so that the 110 versions come first (which IMHO should be the case automatically).
The FileTimeToSystemTime has been confirmed as a bug by one of Krzysztof's co-workers. So there is still no fix that I know of for non-owners to connect via sqllocaldb. But I've shown that both SSMS and sqlcmd can be made to work, so I hope that gets you closer to running.
EDIT
You need to add any non-owner users to the instance, e.g. CREATE LOGIN [MyDomain\OtherUser] FROM WINDOWS; and any appropriate permissions as well. In my test login was failing and generating the wrong error message (the "FileTimeToSystemTime" error message is a bug). You also need to GRANT CONNECT. Once you do this, you will be able to connect from the second user using Management Studio with this connection (the only one I tried):
(localdb)\.\MySharedInstance
But from sqlcmd, I still I get an error no matter how I try to connect:
sqlcmd -S "(localdb)\.\MySharedInstance"
sqlcmd -S ".\MySharedInstance"
sqlcmd -S "(localdb)\MySharedInstance"
sqlcmd -S "GREENHORNET\MySharedInstance"
sqlcmd -S ".\LOCALDB#SH04FF8A"
sqlcmd -S "GREENHORNET\LOCALDB#SH04FF8A"
All yield:
HResult 0xFFFFFFFF, Level 16, State 1 SQL Server Network Interfaces:
Error Locating Server/Instance Specified [xFFFFFFFF].
Sqlcmd: Error:
Microsoft SQL Server Native Client 10.0 : A network-related or
instance-specific error has occurred while establishing a connection
to SQL Server. Server is not found or not accessible. Check if
instance name is correct and if SQL Server is configured to allow
remote connections. For more information see SQL Server Books Online..
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Login timeout
expired.
Though I have verified that the instance is set to accept remote connections. So there is some other hoop that sqlcmd must be going through.
And regarding the sqllocaldb exe, how does this follow any logic? I can see the instance is there via info, I get a proper error message when I try to stop it, I get a message that it is [already] started when I try to start it, but I can't connect to it?
So unless you need sqlcmd access, in the short term I would have the secondary users do their thing with SSMS (once you've granted adequate permissions) and hopefully Krzysztof will have more info on the other items.
Regarding the 4.0.2 update, from http://connect.microsoft.com/SQLServer/feedback/details/723737/smo-cant-connect-to-localdb-instances:
We made an explicit decision not to include .NET Framework 4.0.2 in
LocalDB installer. Installing the .NET Framework update would increase
the size of the LocalDB installer and cause a likely reboot. Since
LocalDB is built to be independent of the .NET, we didn’t think we
should take this cost for every LocalDB installation. Future .NET
versions (including .NET 4.5, now in CTP) will support LocalDB out of
the box. Some developers may also want to opt in for ODBC, PHP
Driver/PDO, and probably JDBC in the future. Those developers will not
be interested in updating .NET.
As the original post suggested, this wasn't as straight forward as anticipated, but I was eventually able to connect via the named pipe.
THIS ANSWER ASSUMES DELETING THE INSTANCE IS OK.
ie: all your data will be gone and that is okay.
I was having the same problem, after upgrading my SSMS.
sqllocaldb i
.\MyCustomInstance
sqllocaldb d
LocalDb instance ".\MyCustomInstance" does not exist!
sqllocaldb i .\MyCustomInstance
Windows API call "FileTimeToSystemTime" returned error code: -2147024809.
In order to get rid of the offending instance I had to create another MyCustomInstance which I guess will overwrite what's already there, and now you can delete it
sqllocaldb c MyCustomInstance
LocalDB instance "MyCustomInstance" created with version 11.0.
sqllocaldb d .\MyCustomInstance
LocalDB instance ".\Octopus" deleted.
Then, start the instance and share it.
Imperative you start the instance first.
sqllocaldb s MyCustomInstance
LocalDB instance "MyCustomInstance" started.
sqllocaldb h MyCustomInstance MyCustomInstance
Private LocalDB instance "MyCustomInstance" shared with the shared name: "MyCustomInstance".
Now, when you need to connect, you connect with (localdb)\.\MyCustomInstance
Install the full .NET framework 4.5.2 or later, then reboot, you should then be able to connect using:
sqlcmd -S (localdb)\.\MySharedInstance
I have found that named pipes generate a new hash when the machine is rebooted, the named shared instance will persist after reboots.
Important to note it won't work until after a reboot.
The problem is you need to quote the db name:
sqlcmd -S "(localdb)\.\MySharedInstance"