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.
Related
So I have this source code of a software which is probably developed in oracle.
Can anybody tell me how can I turn this into an actual software?
I am a newbie.
Screenshot
Those are Oracle Forms (.fmx) and Reports (.rep) executables, as well as a Menu module (.mmx). In order to run them, you'd first have to know which Oracle Developer Suite version it is; might be anything from at least 4.5 over 6i/9i/10g or even later; who knows, they all share same extensions.
Forms up to 6i are client-server; later versions are web-based so you'd have to install IAS (Internet Application Server) or WebLogic server; none of those installations is trivial so - if you can't even recognize what you have, you'd rather not do that on your own - consider hiring a consultant.
Once you manage to set it up, you'd run the .mmx file as it looks as the menu for that application.
However, it's not that simple - in order to run such an application, you have to establish connection to the database, i.e. a schema that contains tables used by this application. There's the "Database" folder - maybe it contains some more useful info, perhaps export file (.dmp), maybe even .dbf files ... can't tell just by looking at the icon.
It might be enough if all tables are owned by the same user; otherwise, application might fail because of missing dependencies.
Finally, I think that your best option is to find out someone who actually knows what it is, which development software was used to create those forms & reports and then see if something can be done. It would be simpler/easier if you had .fmb and .rdf (or .jsp) files instead of executables as you could edit them.
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.
I am trying to create a database project in Visual Studio 2012/2010 where I need the CDC (Change Data Capture) tables , because lot of my views are dependent on the CDC tables. I couldn't find any way to import the cdc schema/tables :(. Read in many blogs that importing cdc is not supported. Is there any work around. Please suggest
Generally you wouldn't really want the CDC tables to be created by a database project, you want them to be created using sys.sp_cdc_enable_table
If you allow the database project to create the tables in a normal manner then the CDC tables would end up existing but their Change Data Capture wouldn't actually be enabled.
Obviously you can script the calls to sys.sp_cdc_enable_table in either Pre or Post scripts, but as far as I can tell neither place is ideal.
If you put the sys.sp_cdc_enable_table calls in a Pre script changes are that not all the original tables exist (on a fresh deploy none of them will exist), or that these original tables will change shape as part of the main deploy that occurs after Pre is run.
If you put the sys.sp_cdc_enable_table calls in the Post script, you can't have Views that rely on the CDC tables existing deployed as part of the main database project deployment (not without errors or warnings in your DB project).
I would suggest not having too many views, functions or stored procs that rely on the existence of the CDC tables, but it sounds like it might be too late for that.
Side Note: Generally speaking you should be using the cdc.fn_cdc_get_all_changes_ and cdc.fn_cdc_get_net_changes_ functions rather than referencing the cdc tables directly, see Querying Change Data Capture data
However, that just moves the problem along one level to those functions not existing in your project.
Unfortunately, there doesn't seem to be a good way to have those extra views without scripting them at the same point that you script your calls to sys.sp_cdc_enable_table
(I'm honestly hoping someone else will come along with a better answer that actually solves the problem)
We came across the same issue recently in a DB project using TFS/VS for builds during the implementation stage.
As Scott correctly said, it's not a good idea to attempt to implement either cdc schema or any objects inside the project/solution, this has unfortunate consequences which you really do not want to experience!
For TFS/VS projects, you should implement a Pre-PostDeployment Script strategy, whereby CDC can be disabled during the PreDeploy process and then the instances are recreated during the PostDepolyment process.
In this way you can assured that the correct CDC instances are created uniformly.
When you consider the dependent views, again, the strategy is not difficult.
Create the view as you normally would in the project, but as a placeholder (e.g. a simple CREATE dbo.vMyView AS SELECT 1 FROM SomeTable). In the PostDeployment scripts, add a further script that executes AFTER the CDC instances have been created, with ALTER statements for those views (e.g. ALTER VIEW dbo.vMyView SELECT Col1 FROM cdc.MyCDC_CT). Remember, a view, once created, can exists even if the underlying table doesn't.
I am a computer science student and my project partner and I are working on a project where we are required to develop a DB (JDBC) for our software. We are capable of doing this, but have hit a brick wall right out of the gates. Our entire project is stored on our shared access dropbox account so we can work on the same classes etc. This has been fine until we attempt to develop a DB that is stored on dropbox. Each time we attempt to open our project in our IDE we receive an issue to resolve: Cannot find derby.jar
Because of this, we each create conflicting path names to the project's derby file, as dropbox is stored on each of our separate machines. e.g "C:..\DropBox\Project\derbyclient.jar"
This in turn prevents each other's IDEs synchronizing with the DB we created.
What a mess, any help (or alternative approaches) would be greatly appreciated.
Ben.
How about making sure your dropbox folders have the exact same path on both computers. This might involv one of you to re-install or reconfigure Dropbox.
Consider using real source control, like Subversion, Git, Mercurial etc. That is also handy if you need to go back to an earlier version of the code. And it is also great to document changes.
I usually create a solution folder in Visual Studio and put my DB scripts in them. I always use at least this set of scripts:
Drop model
Create model script
User functions
Stored procedures
Static data (lookup tables)
Test data (not deployed)
Then I simply combine them and run against an SQL Server so I'm able to recreate the whole DB in a single step (by combining these scripts into a single one and executing it).
Anyway. I've never used projects in either:
Visual Studio or
SQL Management Studio
I've tried creating SQL Server 2008 Database Project in Visual Studio 2010, but I'm somehow overwhelmed by all the possible server settings (which I prefer to stay default as set on the server anyway). So I'm a bit confused: Should I use this project template or should I just do the same thing I always did?
What do you use and why? What are advantages I may benefit from by using either?
If I were you I would continue to do it the way you are doing it. In fact I do! The advantages of having the actual .sql files right there in a folder for you to use/edit/look at in my opinion are far better than the advantages you get by using a DB project. DB Project would be used if you were doing something like Storage Reports, were you have to communicate with like 8 databases and compare then to 8 different databases and save result sets etc... Now don't get my wrong there are advantages of Database Projects, I just don't think they are actually doing much help when you have such a simple setup that works already.
Advantages of the SQL Server 2008 Database Project in VS10:
Not having to switch back and forth
from your current client you use to
communicate with your SQL server.
Decent Data and Schema compare tools.
Gives you a one-click way to reverse
engineer a database into source
control, and keep it up to date.
You can compare projects to physical
databases and vice-versa. (This makes it pretty easy to keep your database up to date, no matter where you make change it: file system database project, or in the physical database itself)
If the current tool your using is not specifically tailored to SQL Server, this one is.
Extremely helpful if you need to do
unit tests directly on the database
without using abstractions.
If you're looking for something a little less complicated, you might want to try SQL Source Control. This won't even require you to maintain scripts, as it doesn't this for you behind the scenes. It will, however, only work as a solution for you if you use either TFS or SVN. And it costs $295...
It has a 28-day trial period, so if you're happy to try it out, I'd be interested in your feedback.