I'm trying to access data on a SQL Server with Azure Data Studio. When connecting to the server it shows a SQL Database and a SQL Pool under Databases. I can see and interact with the Tables of the SQL Database but not with the SQL Pool.
When I use the same connection in SQL Server Management Studio all tables are visible for the SQL Pool.
Any idea what I might be doing wrong in Azure Data Studio?
It works now.
It seems one has to be careful in which order to resume the SQL Pool (this one is paused most of the time) and connect to the SQL Server.
So first resuming the SQL Pool and then connecting to the server seems to have done it.
Related
I have a SQL Server 2012 database on one server, and a SQL Anywhere 12 database on another server. I want to schedule a nightly select query that pulls data from the SQL Anywhere DB to the SQL Server DB.
This is all easily done between two SQL Server databases, even on different servers, but I have no option for "Microsoft OLE DB Provider for SQL Anywhere" and everything I find on the subject seems to assume that both the SQL Server and the SQL Anywhere DBMS are on the same server. That is not an option for me.
Is there some way I can get and install just what is needed on the SQL Server system to let me get the SQL Anywhere provider option? Legally and without involving additional licensing?
Microsoft OLE DB Provider for SQL Anywhere is exactly the right one.
This creates the necessary installer:
Start Menu\Programs\SQL Anywhere 16\Administration Tools\Deploy to Windows
Then just install it on the SQL server and you're ready to go.
What is best practise if we have application using a SQL Server database and we would like to have backup if SQL Server not work?
Our scenario:
We would like to use a SQL Server database (main).
If main SQL Server does not work, we would like to use different SQL Server database with same data.
If main SQL Server works again, we need to sync data back to main SQL Server database.
Failover Cluster is an option, but are they any other options?
My .net windows application uses sql server 2005 database…is sql server 2005 required on the client machines?
my .net application updates tables in the databases, retrieves data also.
If you have a central database server - no, you don't need the full SQL Server on your clients - just the SQL Server client parts.
If you want to run the whole SQL Server 2005 on each machine - then yes, you need SQL Server on each machine in that case. Most likely I'd use SQL Server 2005 Express for local work.
It really depends on your scenario - do you want to have SQL Server locally on each machine?? Then each user has his/her own database and no data is shared.
Most of the time, you would want to have a single, central SQL Server machine and all the clients connect to it, share and use the same data.
Getting this warning when trying to setup a transactional replication. This error occurs when setting up a subscription from sql server express using non impersonated login to the distributor. this works using sql server developer subscrption to sql server workgroup publication but not from sql express to sql workgroup. Im not sure if it is an issue with the agent or what not but the subscription setup is identical to my working subscription other than the ability to choose the login to the sql server agent.
If I'm reading this correctly, you're trying to use SQL Server Express as your publisher. SQL Server Express can only be a subscriber in a transactional replication.
http://www.microsoft.com/sqlserver/2005/en/us/compare-features.aspx#integration
i have just started playing aorund with asp.net mvc and i want to view the database (aspnetdb.mdf) in sql server 2008 management studio
but it doesn't seem to let me view this file.
any suggestions?
You have to attach the database to the SQL Server instance using CREATE DATABASE FOR ATTACH or sp_attach_db, and then connect to the instance with SQL Server Management Studio to view the contents of the database. I am assuming that you are using SQL Express, which would mean that your application is configured to use User Instances where the connection string attaches the database to the SQL Server during code execution. This isn't a optimal way of doing things performance wise since you have to pay the cost to bring the database online repeatedly. If you attach the database permanently to the SQL Instance you will need to change the application connection string because the database can only be attached once since SQL Server takes an lock on the file to prevent it from being changed by another process.