Please advise me on this issue:
I have one default SQL instance in SQL Server 2005(sp 3 x64 bits) called instanceA
Then I installed another 2 instances call instanceB and C.
After that I restore master.bak from production server to this instanceB. The SQL services for this instance could not be started at all since then. If I turned off the default instance services, instanceB can be started. This is because both of the instances are pointing to the same 'model.mdf' file in 'MSSQL.1' folder. Hence both instances could not be started simultaneously.
I believe that in production server, the model path is configured to the default folder 'MSSQL.1' .Is there anyway to change the path to 'MSSQL.8' that belongs to instanceB upon installation so that both instances A and B could be started together?
Thank you.
Related
Setup: A pretty standard data export SSIS package (SQL Server 2016 compatible), created in VS2019/Data Tools and deployed using the SSIS Project Deployment model to the Integration Services Catalog of a SQL Server 2016 instance. The package creates files in a network folder before sending the file out via FTP and putting a copy of the file in a Sent folder.
The project requirements include having the package running on a schedule using "default" parameter values, as well as allowing users to manually run the package using "non-default" parameter values from within a stand-alone application.
Current behavior: the package behaves correctly when run from a SQL Server Agent Job that is configured with a SQL proxy and credentials mapped to a domain login with the proper permissions for the network folder.
Problem: the Data Flow task fails to create the file with a "Cannot open the datafile" error when running the package directly using any of the following methods (even when the "current" session is using the same credentials as the SQL Server Credentials/Proxy used by the SQL Server Agent Job):
Using SSMS to right-click on the package and selecting Execute
Using the DTEXEC SQL utility
Using the SSISDB.catalog.start_execution SQL Server stored procedure
As far as I'm aware, these are the only methods capable of starting a SSIS package and changing the package's parameter values. I either need to get one of the latter 2 methods to work, find another option that allows for changing the parameter values while launching the package, or use one of 2 techniques I'm aware of (detailed below) that would add yet another failure point to the process as well as other potential issues.
Note: If the process is changed to initially create the file on the SQL Server's local harddrive, then the Data Flow task succeeds, but the later copy to Sent folder task fails with a very similar permissions error.
Alternative #1: this technique requires creating a new table, loading the parameter values to the table, changing the package to check the table and potentially set it's parameters/variables based on what it finds. The package can then be launched using a SQL Server Agent Job (for which there are multiple methods to manually launch them) and if the calling object has correctly populated the table, the package will behave as if it's parameters were changed at runtime otherwise it will run with the default values.
Alternative #2: Change all folders used by the package to point to folders local to the SQL Server instance and then create a separate scheduled task/application/whatever, with the valid credentials, that would synchronize or move the files to their proper network folders.
even when the "current" session is using the same credentials as the SQL Server Credentials/Proxy used by the SQL Server Agent Job
This is probably because the account is not logged on locally at the SQL Server, and so it's a Double-Hop Impersonation scenario, and would require Kerberos Constrained Delegation to be configured.
And you are correct in assessing the options. The general solution is to invoke catalog.start_execution from a session running on the SQL Server, and an Agent Job is the simplest built-in way to do this (the others being xp_cmdshell, Service Broker Activation, or SQL CLR).
I am trying to create a default instance of SSMS to run through a few quick tutorials on my local machine. However, everything I am reading is telling me that this default instance should have been created during the wizard. Welp, I have now installed and uninstalled SSMS 2016 three times and am yet to be prompted by anything other than a simple request to install and a notification that the request is complete.
I have read online that I should use the SQL Server Management 2016 Application to create this instance, but every time I try to open that application I get this wonderful error "Cannot connect to WMI provider. You do not have permission or the server is unreachable".
I have tried running the command referenced in this article to fix the error:
https://support.microsoft.com/en-us/kb/956013
But had no luck.
I've also tried to attempt to connect to what might be the default value for the instance:
-localhost
-myip
-(local)
etc..
But when I ran osql -L earlier, it showed no SQL databases on my machine and since my most recent install this command isn't even working.
You dont create instances with SSMS. SQL Server Management Studio is to query and manage existing instances.
You use the Installation media to create an instance.
Look for the Configuration manager to see what instances you have installed.
The default instance is always called MSSQLSERVER.
According to the article you linked to, you probably jacked the installation between the 32 and 64 bit versions of SQL Server.
I suggest to use the setup program and reinstall it.
Due to some problems we changed server name and after doing this we restarted server. We found that rabbitmq service stopped and we started rabbitmq service but we lost total data related to rabbitmq and it is looking like we setup new one and cluster name also changed to new server name. Now i want to switch back to my old cluster or i want to retrieve old data. We are using windows server 2012. How to do this?
RabbitMQ by default, stores the data inside an directory based on hostname.
The default dir in widows is:
C:\Users\{youruser}\AppData\Roaming\RabbitMQ\db
In my case for example is:
C:\Users\gabriele\AppData\Roaming\RabbitMQ\db\rabbit#windowsdev-mnesia
and
C:\Users\gabriele\AppData\Roaming\RabbitMQ\db\rabbit#windowsdev-plugins-expand
Now you should have 2 directories inside C:\Users\{youruser}\AppData\Roaming\RabbitMQ\db with old-hostname and new-hostname.
You can:
stop rabbitmq
backup your old-hostname directory
delete the new-hostname directory
rename the old-hostname directory with the new-hostname
I think that you still have your data in your server.
LEt me know.
Per MSDN Docs: http://msdn.microsoft.com/en-us/library/hh510202.aspx
LocalDB supports two kinds of instances: Automatic instances and Named instances.
I suspect this has something to do with my problem, so I am wondering if anyone knows how something like this gets automatically created. If I can quote from the docs, "One automatic instance of LocalDB exists for every version of LocalDB installed on the user’s computer."
Here is a copy of the relevant section in the above link:
Automatic instances of LocalDB are public. They are created and managed automatically for the user and can be used by any application.
One automatic instance of LocalDB exists for every version of LocalDB
installed on the user’s computer. Automatic instances of LocalDB
provide seamless instance management. There is no need to create the
instance; it just works. This allows for easy application installation
and migration to a different computer.
Different versions of LocalDB will have different instance naming conventions:
SQL 2012 LocalDB = V11.0
SQL 2014 LocalDB = ProjectsV12
I've seen others.
As long as the connecting app's connection string points to the correct instance, all is well:
(localdb)\V11.0
(localdb)\ProjectsV12
If I try to connect with SQL Server Management Studio to either instance (localdb)\V11.0 or (localdb)\ProjectsV12, I CAN, the "stopped" server "autostarts".
If I set the SQL Server instance in VS2013 to either instance (localdb)\V11.0 or (localdb)\ProjectsV12, I CANNOT, the "stopped" server "fails" to start. It attempts to start, but fails.
Here is the error message found in the instance error.log indicating why the instance start failed.
014-12-19 15:12:14.09 Logon Error: 17828, Severity: 20, State: 3.
2014-12-19 15:12:14.09 Logon The prelogin packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library. [CLIENT: <named pipe>]
I may have found a clue here:
On one of my machines where Automatic Instancing works, the sqllocaldb command outputs following:
C:\>sqllocaldb info v11.0
Name: v11.0
Version: 11.0.3000.0
Shared name:
Owner: AM\Z617699
Auto-create: Yes <-- Yes? - and I have no idea how this is set.
State: Stopped
Last start time: 12/18/2014 5:18:46 PM
Instance pipe name:
On one of my other machines where Automatic Instancing does NOT work, the sqllocaldb command outputs following:
C:\>sqllocaldb info v11.0
Name: v11.0
Version: 11.0.3000.0
Shared name:
Owner: AM\Z617699
Auto-create: No <-- No? - and I have no idea how this is set.
State: Stopped
Last start time: 12/18/2014 5:18:46 PM
Instance pipe name:
I have spent days trying to find the answer to this question. Here is a link to an MSDN forum post that outlines all the unsuccessful steps I have taken to resolve this issue:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/83ad45d5-15c3-4463-bc0c-6c4899bf947e/localdb-visual-studio-2013-will-not-automatically-start-the-sql-2014-localdb-projectsv12-instance?forum=sqlexpress
The workaround is to just start the instance manually before you start VS2013. I'm just trying to resolve this issue so I can get an "Automatic Instance" image for all our developers.
I hope you just know he answer. :-)
Thanks, Dave
I had the same issue.
I resolved it by deleting and recreating the instance from command line:
Open the command line
Delete the session by typing: sqllocaldb delete "v11.0"
Recreate the instance with: sqllocaldb create "v11.0"
The new instance allows auto creation, and solves the issue.
The solution was taken from:
http://answers.flyppdevportal.com/categories/sqlserver/sqlexpress.aspx?ID=8bcb5f1e-0240-4df3-8a5e-7e3e73e1c45b
I had the same problem on VS2015 and SQL2016
the problem my dev station is a laptop, project explorer i think uses tcpip connection, while SQLeplorer local file or so.
It worked after i made sure that SQL used the Network card, and that it had a cable plugged in (so SQL could server the request over TCP using that IP) which it couldnt over wifi (by default?)
I had the same problem. One of the problem may be an older installed version of this product. Try to delete the database instances which are located in the following folder:
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Microsoft
SQL Server Local DB\Instances\VeeamEndPoint
After that it works for me!!!
I built an application for a client that requires SQL Server 2005 Express. Everything worked fine on all the machines except for one. On this one they already had an application that uses SQL Server Express, so it was already installed on the machine, but nobody knows which application uses it or any usernames/passwords.
Can I simply install another copy into a different folder? This just doesn't seem right to me, and I know this has to be a common scenario. Can someone point me in the right direction on how I should proceed?
Thanks!
Darvis
Yes you can just install into a different directory, as a new "named instance" of SQL Server Express.
To install, follow Step 8 on Microsoft's Install How-To:
On the Instance Name page, select a Default instance or a Named instance for your installation. If you select Default instance, an existing default instance will be upgraded. If you select Named Instance, specify an instance name
So what you need to do is specify the Named Instance and specify your own instance name, and connect to it using the URL format as above.
As the Microsoft How-To mentions, the default installation is a named instance as well, with the name "SQLExpress", which is why if you want to stop or start the service with net start or `net stop' you need to write something like:
net start mssql$sqlexpress
and the hostname part of the connection string for a default SQL named instance is:
.\SQLEXPRESS (or localhost\SQLEXPRESS)
You should be able to log into it using Integrated Windows Authentication using an administrator type account on the PC, and use that to reset passwords on any SQL server type logins.
Failing that, yes, you should be able install a "named instance". You connect to it by supplying "hostname\instancename" as the server name.
In all likelihood, the culprit is Outlook's Contact Manager.
You should just uninstall the "feature". If you can't, you can create an additional instance of SQL Express, which you can access as COMPUTERNAME\INSTANCENAME.