I have just implemented my DB Schema with Jetbrains new DataGrip IDE. The schema now exists on my DB server instance that is running locally.
In other IDE's I can save the work as a "Project" or save the SQL to a file. I don't see any option in DataGrip, except for Copy DDL, which I have tried and it copies my schema along with a lot of other stuff.
Is that the only option or am I supposed to do it through a PostgreSQL management tool. I want to save my work.
Thanks. Also, please don't just mark this to be closed. I have seen many other questions like this on StackOverflow. i.e. Asking how to perform some action on a tool related to software development.
You are in "default" project by default. Go to File/Project and create your own which can be opened later by File/Open recent, for example.
Related
When publishing a database from Visual Studio, there are several options to "do not drop" an object if it is not in the Source. However, it seems that there is no option to avoid dropping schemas. Do anyone know if this is possible to achieve, or do I have to manually edit the publish script?
It would probably be simplest just to add the schema to the project. The script would be simple enough, we use:
CREATE SCHEMA [api]
AUTHORIZATION [dbo];
(Also, I wish I'd seen this question much earlier, hopefully this isn't too late to help someone.)
IntelliJ IDEa 2017.1.1
There seem to be two different ways of being connected to a database in IDEa. I am connecting to an Oracle db.
There is a DB browser, which is much less functional. I need to provide a connection to it. Then it looks a bit like this. This is the interaface I'd rather avoid.
Then there is "Database" which has a different interface, but works very similarly and has a better user experience.
They provide different functionality when editing a file. When I create a new scratch file, the better feature is used - code completion works with the content from the Data sources from the Data Source and Driver interface. However, when I edit an SQL project file, I have to use the other interface - I have to select a connection from the DB Navigator.
A colleague of mine uses IDEa too, but for him, however, even SQL files use the Data Sources and Drivers interface and the content of those connections as source for auto completion. Why this difference? Why two interfaces that do the same? How can I set IDEa to use the Data Sources and Drivers for my project SQL files?
DB Navigator is a third-party plugin that duplicates and overrides some of IntelliJ IDEA's database access features. Uninstalling the plugin should get you the same UI as what your colleague has.
We want to start using the TFS version control on our project. I read the tutorial and noticed that TFS creates tables in the sql db. My questions are:
What are these tables for?
Where is the vs solution actually stored?
How can I use more then one instance of our solution from another computer (another developer)?
TFS stores pretty much all its data in few SQL database: source control, work items, build definitions, build results etc.
In the SQL database for the Team Project Collection, specifics about which tables etc should not matter to you. Users setup a workspace which maps the directory structure in source control to a place on their local disk.
I'm not sure what you're asking here, can you try clarify your question?
Sqldeveloper 2.* had a very good tool to view database schema. here is the screen-shot of how it can be launched:
Was this tool removed from SqlDeveloper 3.* and is there something similar there?
P.S. I tried googling and reading manuals for some time, of course.
The latest versions of SQL Developer still have the data modeler.
http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html
here's a link that shows you, I use it almost daily in the latest version of sql developer (or at least 3.1.07 that I am using -->whoa they've updated to 3.2 I'll go get that later)
you can still goto Tools->Data Modeler but you can also OPEN and SAVE the datamodeler via the File->Data Modeler context menus (it seems to have been 'combined' with SQL DEVELOPER to the point where you save it independently).
If you go to VIEW->Data Modeler->Browser you can then create models etc and save them via the aforementioned menu item in SAVE.
Currently I'm using Visual Studio 2012 RC and SQL Server 2012 RTM.
I'd like to know how to re-deploy/re-create a test database for each test run.
Keep in mind I've a SQL Server database project for the database using Visual Studio 2012's template.
Actually I'm not very sure about an idea I got in my mind, but .testsettings file has Setup and cleanup scripts. Is this the way to go? For example, a PowerShell script reading the database project generated script and executing it against the database?
I guess there're better ways of doing that and it should be an out-of-the-box solution but I ignore it and Google doesn't help me in finding the right solution.
As mentioned you'll probably want to use the VS 2012 .Local.testsettings > Setup and Cleanup scripts to create / tear down you SQL Server database.
For the script you may want to use powershell with a .dacpac (rather than just a T-SQL script), since you are using a SSDT project. Here's a link to some example code - in particular you may want to take a look at the 'Deploy-Dac' command.
If you are unfamiliar with .dacpacs as the (build) output of SSDT-created database projects, take a look at this reference link.
Edit: Although this doesn't answer the question in a plain SQL Server way, an easy Entity Framework approach would be the following: I found that I could create and destroy my database every time correctly by using the DbContext.Database.CreateIfNotExists() and DbContext.Database.Delete() methods in my setup and cleanup phases of my tests.
The fastest solution, while a bit of a hack, is really straightforward. You can set the DB Projects properties under the debugging tab to "always re-created DB". Then test in two clicks, do a debug/build, then run all tests. You should get a freshly built DB on localDB for you tests to be ran against. You can also change the target for the debugging DB (again the DB projects properties) to whatever you want, so you can deploy to a .dacpac, or to an existing SQL DB or wherever. It means testing in two steps, and if your build is long, it may be annoying, but it works. Otherwise, I believe scripting is your only option.