Is it possible to use SQL Dependency with SQL Server Express 2005 which comes with VS 2008?
Yes. It works fine with named instances as well as default instances, on any SKU (Express, Web, Developer, Standard, Enterprise and Data Center). You can read The Mysterious Notification to understand the underlying mechanism that powers SQL Dependency.
When you open a database using the connection string option AttachDBName you are using a User Instance (aka RANU). The user instances attaches the MDF file using and by default a newly attached database will disable Service Broker in the database. Because the Query Notifications use Service Broker to deliver the notification, it implies that a database with Service Broker disabled cannot create a notification subscription, unless it takes the necessary steps to re-enable Service Broker.
This article suggest that it will work fine as long as the express edition database is a named instance:
http://www.code-magazine.com/article.aspx?quickid=0605061&page=5
HTH
Related
We're trying to deploy a DACPAC to a new server via MS Release Management Studio. We've successfully deployed to other new servers with the same DACPAC with an existing restored database prior to data-tier upgrade. Proving that the DACPAC and deployment process is working.
The only difference is this server has Always On Availability Groups (AOAG) and the target we are deploying to is the group listener. Following the advice from here:
You have to deploy it to the Listener, which will in fact redirect your connection to the primary replica of your AlwaysOn Availability Group.
The changes will also be transferred to the secondary replicas.
The listener enables a client to connect to an availability replica without knowing the name of the physical instance of SQL Server to which the client is connecting.
So normally you can use this listener name in the Release Management Studio like another SQL Server Instance.
Having tried to manually upgrading the data-tier application using the listener it states that the target server is not accessible.
Does anyone have a process for this or has had some experience they can share as to why this is happening and what I can do to get past it?
UPDATE (resolved):
It looks as though our server was patched which caused a failover to occur. The secondary replica didn't have an account setup for our Release Management Studio user.
Also, our DBA finally chipped in with our replica's being set to read-only.
Consequently, we had made some discoveries, such as DACPAC's will upgrade a database to a data-tier application even if they are not registered.
And although you can deploy a DACPAC to your primary replica as a DAC, the secondary's won't be registered as DAC's unless you manually upgrade / register them. Useful to know.
Thanks to all those that asked questions :)
It looks as though our server was patched which caused a failover to occur. The secondary replica didn't have an account setup for our Release Management Studio user.
Also, our DBA finally chipped in with our replica's being set to read-only.
Consequently, we had made some discoveries, such as DACPAC's will upgrade a database to a data-tier application even if they are not registered.
And although you can deploy a DACPAC to your primary replica as a DAC, the secondary's won't be registered as DAC's unless you manually upgrade / register them. Useful to know.
Thanks to all those that asked questions :)
This also happens becasue your database recovery setting will be simple. In Availability group or mirroring case it should be full
We're in the final phase of migrating our SQL Server on VM to Azure SQL Server. What is the most time-efficient approach to getting our existing SQL Server Agent Jobs out to Azure? I've noticed that inside of SSMS, when connected to an Azure SQL Server, the Agent does not exist - we were aware of this before migrating, but I have yet to have found whether there is an Azure service that replaces the SQL Server Agent Jobs functionality.
There are a number of options.
If you need timed execution of some data momement, Azure Data Factory can be a good replacement.
There is also an Azure Scheduler, that is often mentioned as an alternative. However, I believe that would work better on API's than directly on a database.
I think the best option is Azure automation and create a runbook that connects to your database and performs some action.
An interesting blog that details these options in more detail can be foond at: https://blogs.technet.microsoft.com/uktechnet/2016/02/05/is-sql-server-agent-missing-from-azure-sql-database/
I was going to process the cube deployment and found the error.
I changed the target server name from 'localhost' to this,and tried different way but in vain.
Here is the snap from my SSMS
You may have multiple issues going on but the first and foremost is you do NOT deploy SSAS Multidimensional [MDX] models to a SQL Database Engine Instance!
Unless you have a very odd configuration ATI-PC\MSSQLSERVER should point to the default MS SQL Server Database Engine Instance NOT an SSAS MDX instance!
The SSMS screen shot you show is for the local host connection you show is for a Database Engine with SQL Server Authentication (SA), which I would assume the instance is called MSSQLSERVER which is the default instance name.
1) What is your SSAS instance name?
2) Does your windows account have permissions? SSAS doesn't allow for SQL server authentication so it must be windows authentication.
3) Is SQL Browser running?
4) Have you configured SQL Browser to allow for the protocols and to allow connections from both Localhost and ATI-PC(InstanceName)?
to connect to Analysis Services Change the Server Type. When first launching SSMS you can do that via changing server type and then modifying the server name to the appropriate name.
If your SSMS is already open you can select "Connect" drop down and choose Analysis Services.
Check on your SQL Browser Configuration by Launching "SQL Server (Version) Configuration Manager" then step through the different areas as far as how to configure it is somewhat self explanatory and because you are deploying an AdeventureWorks cube I would surmise that the configuration would be earlier in you tutorial you are working on.
I am sure that you have 'SQL Browser' service running in services.msc. Still I doubt your account which you logged in has access to SSAS and also to connect to that underlying SQL Server. Try checking both for the access, if you selected deploy as service account check that account has access in SSAS. If still you have issues trying checking the eventvwr if you are getting any more errors. If it is development box try recycling SSAS services and try deploying?
If I only have one VM in Azure I can get outtages at any time when Azure decides to reboot/reprovision my server. Therefor I have to at least two servers in an availability group to get a stable environment.
This is used by a web app (web roles) and an important aspect is that the databases are used for reading. They will get their data from sql replication from an on-premises database. The replication can be done separately to each database. Additionally using Azure Sql Database is not an option because we have not be able to implement a durable data sync solution (using Microsoft Sync Framework), Sql Database does not support sql replication, and constantly uploading the complete database would be too slow.
How should the database VMs be hosted and accessed to able to use Sql Server VMs?
One alternative is to use AlwaysOn Availability Groups. This however requires Sql Server Enterprise edition and the price is very high considering I need to have at least two servers. In this scenario I at least get one connection point behind which a sql server always should be answering. This is however beyond our reach because of the cost.
One alternative could be to use Traffic manager to round robin the connections. When the database server goes down we have to wait for TTL to expire before the webrole would refresh the ip address so that seems a big problem.
How should one host Sql Server VMs in Azure?
You can use FailoverPartner parameter in the connection string to specify the secondary replica address. You can see more in this article.
We have two Sql 2008 R2 database. First and main one is on-premise which is used by our stock management and accounting systems.
The second is for our web site and it is on a 3th party hosting firm and that database is updated manually by a standard XML file operation
(creating XML from on-premise database, sending it to web server, reading from XML file & insert/update/delete web database)
we need to get rid of that manual XML operation and sync that two databases automatically, but problem is our hosting firm does not allow "Replication" or "Linked Server" facilities on their "Sql Server" system. That's way we can not sync databases with these "Sql Server" facilities.
I am trying find out sync alternatives for that scenario without changing the hosting system.
What options can we use ?
Is Microsoft Sync Framework can be used for this scenario? ( I'm not sure if it is just for the Microsoft Azure Sql system)
Thanks…
if you're fine coding, then Sync Framework can do this.
Sync Framework can sync SQL Compact, Express, Server, Azure or LocalDB
But bear in mind that Sync Framework will need to create some Sync-related objects on your databases (triggers, stored procedures, tables, etc...)
It sounds like you need a hosting provider that provides these services.
It is typical for a hosting provider to provide an on-demand or always VPN connection to the production servers from the client location to the servers at the hosting location. Such a service is often needed for support of online systems. If you had such a connection then having SQL Server do syncs would be no problem.
Any major (Rack Space, Peer1, etc) provider would be able to set up such a system.
It probably won't be as inexpensive as your current provider.
Well if changing a provider is not an option, at list in the short term and you need something right now, you can always automate parts or all your current process.
For that you can at least use:
PowerShell (or even plain old cmd.exe) script(batch) and bcp.exe to export and import your files on both ends and PowerShell and ftp to transfer your files from one server to another.
SQLServer Integration Services on premises to export and send files via ftp to your hosting location. And SSIS to grab and import those files at your hosting location.