I've never liked the User instance when attaching a database in linqpad. It only seemed to work for the SQLExpress edition not the full one. Now it's being depreciated in SQL Server 2012 (which is now released), do you intend to use the new localdb feature instead or in addition to the user instance?
LINQPad unticks the 'User Instance' checkbox by default if your server name doesn't contain "SQLEXPRESS". However, it does not disable the checkbox because it cannot be certain that that instance is not a SQL Express instance simply by the name.
LINQPad will still need to support user instances because it must still support SQL Express 2008 and SQL Express 2005.
Does it let you connect to a SQL 2012 localdb if you enter "(localdb)\v11.0" into the Server box?
Related
I have tried creating a sequence for my table in Microsoft SQL Server Management Studio 18. I have a syntax error for some reason (although I have checked multiple times the syntax), but I cannot even find the sequences folder for my database. I have also tried not writing the schema name, but the same error appears. What might be the problem? Where do I go wrong?
Here is a screenshot of the problem
First note that SSMS (SQL Server Management Studio) is just a client application that talks to a connected SQL Server instance in the background. So SSMS only passes your SQL statements to the connected SQL Server and shows you the results that SQL Server returns. Nothing more.
What is the version of the SQL Server instance to which your SSMS is connected? (You can check it quickly by executing the SQL statement PRINT ##VERSION.)
You should be aware that the CREATE SEQUENCE statement is only supported by SQL Server 2012 and higher.
I have connected to my SQL azure server using SQL Server 2012 Management Studio and I cannot edit any of my table's schema or the data in it. When I right click on the table the options are missing. Am I doing something wrong?
Not that I am using SSMS 2012, but in 2008 R2 is generally the same. There is no GUI for neither table designer, nor "Edit top 200 records". You have to begin diving into the DDL and DML for SQL Server and give up GUIs. One way you could use GUI to some extend, especially for DDL is to use the portal provided Windows Azure SQL Database manager. You can find a link to it when you go to your database from either the new or the old portal (Manage). Other way is to use some third party tool, which I am not aware of.
Here is the link to that manager from the new portal:
Another option some people may find helpful, if you have and use Visual Studio then you can link to the server in ServerManager, connect to the database, and then design and edit data directly.
My 2008 R2 version of SSMS had the same problem. I downloaded 2016 CTP3 SSMS which has Azure support and everything is normal for the Azure Databases.
https://msdn.microsoft.com/en-us/library/mt238290.aspx
I did lose my connection history information so beware.
I have been assigned the task of converting an SQL Server Database to an SQL Azure Database. During the process I encountered these problems:
Cannot use the Object Browser in Management Studio 2008 v10. Is there a fix to this?
I cannot create new Users under the Security Section since I cant use the Object Browser.
Basically I want to create an Admin user and NonAdmin user each with their own privileges to UPDATE, DELETE, INSERT commands on different tables in the database.
Basically my web application has a sign up form how can I associate new registered user to the SQL Azure Roles during the sign up process to limit them from perfroming ertain commands on the database tables?
Just answer your questions.
1, No SSMS 2008 doesn't support Azure. You MUST use SSMS 08 R2.
2, If you are using SSMS 08 R2 the object explorer will be appeared. But the features when connecting to SQL Azure will be very limited. The designer and dialog are disabled which means all tasks should be done by using the SQL script.
3, Not pretty sure what you mean, but you can try what you are doing on SQL Server since SQL Azure is very very similar with SQL Server.
Data-tier Application and SQL Azure MW are good tool for migrating your existing database to SQL Azure. But you can still use the build-in feature in SSMS 08 R2 to migrate the database schema as well. Just use the Generate Script menu item from your local database, and make sure you selected SQL Azure in the "Script for the database engine type".
Check out the official page on how to move data etc..'Migrating Databases to SQL Azure'
http://msdn.microsoft.com/en-us/library/windowsazure/ee730904.aspx
Also check out the 'SQL Azure Migration Wizard v3.8.3'
http://sqlazuremw.codeplex.com/
Migrating Databases to SQL Azure by Using Data-tier Application Export and Import is probably your best option, the migration wizard is a great tool, I have used both.
re: 1 you need service packs, I'm not sure 2008 V10 is supported, get the latest version or upgrade to 2008R2 Mgmt Studio (latest)
2: use the tools above
3: not sure here what you are trying to do to correctly answer.
hope that helps...
I can't see to find a quick explanation of the differences so I can figure out which to use.
One is for a server one is for a Database? Im not sure what that means..
Basically we are doing a new web app and I want to see what these project types can offer me in terms of tracking the DB code/schema etc..
SQL Server 2008 Project: this is used to create a SQL-CLR module, e.g. create a stored proc, a function, an aggregate etc. in C# (or VB.NET), that will be run inside SQL Server.
When you create such a project, and you click "Add New Item" in Solution Explorer, you're given the choice of creating a stored procedure, a trigger, an aggregate, a user-defined function, a user-defined type or a helper class. These will all be compiled into a .NET assembly, which will be deployed to SQL Server and be executed inside SQL Server in the SQL-CLR runtime environment.
SQL Server Database Project: that's only a collection of SQL scripts to be run against a database, to create and manipulate database objects
In a SQL Server Database Project, you basically only get to add SQL scripts - .sql files. Nothing else, really. So it is indeed quite different from the SQL Server 2008 Project type!
The answer here doesn't seem to actually answer the posted question. "SQL Server 2008 Server Project" "SQL Server 2008 Database Project" are both things that exist in Visual Studio 2008 Database Edition, but sadly while there isn't one named "SQL Server 2008 Project" as the answer suggests, there is one "SQL Server Project" that matches the description. Moreover, there isn't a project type anymore called "SQL Server Database Project" (at least not in Visual Studio 2008 Team Suite), although the description given above seems to describe the much older database projects that were at one point available in VS.
After thinking about it further, I'm going to guess that marc_s doesn't have the Database Edition (otherwise known as Data Dude or DBPro) installed. Correct me if I'm wrong.
Sql Server 2008 Database Projects and Sql Server 2008 Server Projects seem to do basically the same thing. I would have hoped that the Server projects would be used for the installation and configuration, and change management of a Sql Server instance, while Database Projects would be used for individual databases inside them...but this doesn't seem to be the case. Has anyone actually been able to determine the differences between them?
After playing around for a bit, the only difference I've been able to find is that Sql Server 2008 Server Projects will always deploy to the master database on the server you deploy to, regardless of what kind of database you import (master or otherwise) when you create the project. So in that case, Database Projects are for your business databases while Server Projects are specifically for the master database on the server that houses your business databases.
Edit: After scouring the VS2008 documentation a little harder, I came across this specification:
"Deploying Server Projects
A database project can contain definitions for database objects, for server objects, or for both. In most environments, developers can change database objects, but only the database administrator can change server objects. You can enforce this restriction by putting server objects in a separate project (known as a server project). You can then restrict version control so that only your administrators can change the server project. In a staging or production environment, the server project and its objects will most often be deployed separately from the project that contains the database objects.
You deploy a server project by using the same procedures that you use to deploy a schema project."
http://msdn.microsoft.com/en-us/library/dd193413.aspx
My development machine has SQL Server 2008 Developer edition on it. A production server I am going to do some development for has SQL Server 2000 on it. Is there a way to create a 2000 database using my 2008 developer edition? Or do I need to create it on the 2000 server and move it to my development machine?
It will not be possible to move the development database into production. Once a database file has been upgraded to the SQL 2008 format, it is impossible to downgrade to SQL 2000 format.
You should focus your development on creating T-SQL scripts instead of creating database objects. This includes initial database creation and any subsequent schema changes. Perhaps you can use a version based approach for your schema and catalog data. As long as you don't use any SQL 2008 specific functionality, the scripts will run fine on SQL 2000.
Setting the db compatibility level to 80 on development will help making the behavior of the 2008 server closer to the 2000 server, but it does not mean the 2008 specific features will not be usable. You have to pay attention and make sure every functionality and feature you use in development will also be available in SQL 2000.
create a database in 80 compatibility mode and you should be ok with regards to sql you use. but you can't restore a 2008 db on a 2000 server.
I suggest you try it this way:
If your SQL 2008 database, right click, select Tasks, Generate Scripts. Now select your database, select your options in the next window (like script Drop, script Data...), continue through the wizard until Finish.
Now SQL will make your qualified script and it is ready to run.
It depends on how you're going to get the new database back to the production 2000 server; if you create it in your 2008 instance, you can't back it up and restore it to 2000, even if you create it in compatibility 80 as Mladen noted; but you could generate scripts to export your database to the 2000 instance, as long as you don't have to copy any of the data in the tables.
If you need to do a full backup and restore of the new database, you'll be better off with a 2000 instance to connect to for development, MSDE could be installed as a named instance alongside the 2008 edition.
yes, the database can;'t be restored from SQL 2008 even with 80 compatibility on SQl 2000 instance.
If you have to restore , script the DB and objects and recreate them on SQl 2000.
-Ashok