I have a large database project and I am trying to publish it to Azure. I have done the following:
In the project settings, changed Target Platform to Windows Azure
On Azure Made sure I am on Standard tier S0
Made sure the Server Version is V12
Changed the Timeout for the publish
Tried creating a new SQL Server database
All result in a ton of errors a couple of which are:
ForeignKey: [xxxxxx] has an unresolved reference
ROWGUIDCOL is not supported for the targeted platform
I tried searching and tried everything I saw with no luck. Also, I need to be able to publish as things change, so using the migration tool is not an option.
Thank you
Eric
That was correct. I just needed to update my SSDT. I posted this as the answer before, but it never showed up.
Thank you
Related
2 years ago, we had Corporate version of Kaspersky AV on our server, which installs MS SQL and creates an engine for itself to function properly.
We do not use Kaspersky anymore. Also we have old accounting software stuff in there which we do not use anymore.
I want to delete that engine as I will be creating a new DB for an module I coded for internal company use.
Below is the image for my current scenario inside management studio.
How can I remove the KAS_CS admin thing and create a totaly new engine where I can start creating databases inside from scratch?
Any help is appreciated. (In case this is the wrong place to ask the question, please let me know so that I migrate it there)
It looks like your current SQL Server engine is from Version of 2005, which is completely out of date, unsupported and everybody already forgot how to deal with it.
That means you better uninstall it completely: (https://technet.microsoft.com/en-us/library/ms143412(v=sql.90).aspx) and install SQL Server 2016.
We originally dismissed using database projects in conjunction with TFS as our solution for our deployment and soucecontrol needs. However, in the interest of thoroughness, I'm exploring and prototyping it.
I've set up my database project (with add to source control checked). I've checked in the changes. Now, where do you develop from?
I've tried ...
connecting to the remote development server to make changes
syncing schema to (localdb)\Projects and making changes there
directly in the Source Control Explorer
With option 1 and 2 I don't see an automated way to add code to source control. Am I suppose to be working in the Source Control Explorer? (this seems a little silly)... Is there a way to commit the entire solution to source control? My apologies in advance, I'm a database developer and this concept of a "solution" is very foreign to me.
Also there were a lot of chatter about Visual Studios doing a lot of ugly things in the back ground that turned a lot of development shops off of database projects. Can someone share your experiences with me? Some of the pitfalls and gotchas.
And yes, we have looked at Redgate SourceControl (very nice tool).
Generally people do one of two things:
Develop in Visual Studio, via the Solution Explorer. Just open the project like you would any other project, add tables, indexes, etc. You even get the same GUI for editing DB objects as you get in SSMS. All changes will automatically be added to TFS Pending changes (just like any other code change), and can be checked in when you're ready.
Deploy the latest DB (using Publish in VS) to any SQL Server, make your changes in SSMS, then do a Schema Compare in Visual Studio to bring your changes back into your DB project so they can be checked into TFS.
I've been using DB projects for many years and I LOVE them! Every developer I've introduced them to, refuses to develop without them from that point on.
I'm going to explain you briefly how we use DB projects with TFS.
We basically have one DB already done and if we require any changes or new tables we create them or alter them directly in SQL Server (each developer has its own dev SQL Server).
Then in VS from the SQL Server Object Explorer we drag the tables we want into the DB project so when we check in the changes, every user in TFS would be able to get them and then publish that project that will generate and execute a script into the DB.
This is the way we use to develop when we need to add specific tables or records to the DB so we don't have to send emails with scripts or have them stored in an specific location (even with source control). This way we can get latest version of the project and publish it to ensure we have the latest DB version although it requires the user (who made the changes) to add them to the DB project.
Other way could be to do all the changes (and can be done without any problem) directly in the DB project and then publish it. That one would be a more right way to do it so you do all the changes directly in a source controlled project, but as you know, is always more comfortable to work directly through the SQLMS.
Hope this helps somehow.
We use the SSDT tools and have implemented the SQL Server Database Project Type to develop our databases:
http://www.techrepublic.com/blog/data-center/auto-deploy-and-version-your-sql-server-database-with-ssdt/
The definition of database objects and peripheral SQL Code (e.g. functions, sprocs, triggers etc) sit within the Visual Studio project and all changes are managed through VS. The interface is very similar to SSMS and, at this point doesn't cause any issues.
The benefits of this approach for us are as follows:
An existing SQL database can be imported into the SQL Server Project and managed through Visual Studio.
SQL object definitions & code can managed through the same version control system as the rest of the application code.
SQL Code can be checked for errors within Visual Studio in much the same way as you'd check your C# / VB for compilation / reference errors.
You can compare database schema's (within Visual Studio) between environments and easily identify key changes that you need to be aware of.
The SQL project can be compiled into a DACPAC file for automating deployment to different servers using a CI / Build Server (using the sqlpackage.exe utility without any custom scripts or code).
In essence developers can have a local version of the database to work on but would manage any changes through VS, then publish the changes to their local database. Once the changes are complete, the changes are committed to your version control system and then built centrally & automatically through a CI / Build server to ensure that all changes integrate and play nicely in much the same way that your other code is.
Hope that helps :)
I have started working with an MVC4 project that has a DefaultConnection enumerated in the web config. (sql server 2005 on a shared dev server)
In an attempt to use MVCScaffoling I've followed tutorials then when I run the scaffold controller tablename -force command line I reload the list of sql server database tables do not see the expected
All the existing scaffolding operations work, including the many to many relationship and everything.
However the tables arent' in the databse, so they must be somewhere else. Where are they? How do I tell MVC scaffolding to do all the work on DefaultConnectionas opposed to self-determining the location to scaffold at?
If there is any at all, the database file will be located in your App_Data folder. You will not see it right away until you click on the show all files icon above your Solution Explorer.
I am not sure what reasons you have on doing scaffolding, but if i were you, i would do Code First. That way, you know where everything is and you know you wrote most of it yourself.
Also if this is development, why are you sticking with old server when you could easily be working with 2012?
Ahhhh... this blurb:
http://www.codeproject.com/Articles/468777/Code-First-with-Entity-Framework-5-using-MVC4-and
Says:
Note: Entity framework will always try to connect to the local SQL Server Express database (.\SQLEXPRESS). Starting with EF 5, Ef will use LocalDb if it doesn’t detect SQL Express running. SQL Express will always get precedence if it is installed, even if you are using Visual Studio 2012.
So it would appear that Scaffolding will not allow me to choose the database where it all happens. Which is a bit of a pain, since I want it to be in the same place as my user tables which do reside in the database specified in DefaultConnection.
I have a database project in Visual Studio 2012 that requires access to a database not of my design through a linked server.
My initial approach was to script out the access to the database in 4-parts [server].[database].[schema].[table]. This approach throws SQL71562a and SQL71501 warnings/errors.
Through research I note that what I need to do is to create a database reference. My question would revolve around that process.
I thought the right thing to do would be to generate a DACPAC from the other vendor's database as it exists on the server - but I am unable to generate the DACPAC as it fails in SSMS (I think due to encryption).
My next idea would be to create a project that has the schema that I need from that database defined and then reference that (I haven't tried this yet as at first guess it is probably the wrong way).
Any help on this would be appreciated. Thanks in advance.
SSMS is very pedantic when it comes to extract DACPAC files.
You can however, use the SqlPackage utility for that:
SqlPackage /Action:Extract /SourceServerName:YourServerNameHere /SourceDatabaseName:YourDatabaseNameHere /TargetFile:YourDatabaseNameHere.dacpac
I had an issue just like that, in which this solved it, and documented it in:
http://tangodude.wordpress.com/2014/02/05/referencing-the-sql-server-data-collectors-management-data-warehouse-in-your-ssdt-database-project/
Creating a dummy/stub project does work though, but using a DACPAC file reference is much much simpler.
In the SO podcast episode 54 Jeff talked about using Visual Studio to save all the database objects to individual files. This sounded like just what my team needed to better implement database schema changes into TFS and I told my lead about it. He thinks it's a great idea to.
Unfortunately, so far I've had no luck getting this to work for me. One of my problems is that I don't have SQL Server installed on my local box (dept policy). I'm obviously doing something wrong.
Can someone give me a rundown of the steps or provide a decent link?
Thanks!
1) Create a connection to the database in Server Explorer.
2) Right-click on the connection and select Publish to provider...
3) Next, Script to file, Next, Types of data to publish should be Schema (unless you need some initial data), finish.
4) Add script to the project and check into source control.
He was referring to a project type in VS that supports managing databases, including (if you set it up correctly), versioning your database publishes.
Check out this article on Database Projects in VS
You want to use the GDR 2. (Sometimes called Data Dude)
This allows for a completely offline solution. You don't need to have SQL Server installed on your machine for this to work. (In fact the GDR is the first version that does not care if you have SQL Server installed.)
I use the GDR for my db (a team of 3 devs and 2 testers) and it works GREAT!
Here is a link for the GDR 2 release:
http://blogs.msdn.com/vstsdb/archive/2009/04/21/microsoft-visual-studio-team-system-2008-database-edition-gdr-r2.aspx
And this is a link to the actual bits:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed
The basic use is to import from an existing DB and server. (You will probably want a server project and 1 or more DB Projects)
You can then make your changes off line. When you are ready to send you changes back to the DB you can delploy (make sure you set up your deploy options first as I think the default is to drop the db and re-deploy). You can also do a Data->Schema Compare in Visual Studio and comapre your project to your database then get a script of changes from the diff output.
It takes a bit of work, but it really allows great source control and is easy once you get the hang of it. (I have my db auto deploy in my night time build twice a week.)
If you're importing an existing database schema, its important to get the right database project. You should likely be using "Database Projects\SQL Server 2005 Wizard".
Visual Studio requires a database connection it can use to create temporary copies of the databases it is working with. It sounds like this is the issue. Do you have SQLExpress on your local box? Use that as the deployment target (server name would be .\sqlexpress if . does not work).
As an alternative, grab update GDR 2 for Visual Studio. Allegedly, it allows one to work with database projects without using a local instance of sql server to deploy temporary working copies of the database.