I'm using NetBeans and I need to connect to Oracle Database.
I set up the driver and the connection and it all works fine. I can run queries on this connection just fine (through the IDE).
The problem is this- The tables I want to work with are not defined on the same schema that I use for the connection, although, my schema does have all the premissions to view and alter those tables.
But since the tables don't belong to this schema, they are not presented in the Tables node of the connection in NetBeans, and I can't use the wizard in order to create entities for those tables.
Any solutions?
Thanks, Malki.
Does NetBeans work with synonyms ?
If so you could try creating synonyms in your connection schema pointing to the tables in the primary schema.
If it is just for the purposes of the Wizard, grab your own development database and create copies of the tables there. Generate your app against connections to that database, and then just change your connection when you are done.
You app may want to issue a 'ALTER SESSION SET CURRENT_SCHEMA = ....' on logon so that it looks at the appropriate schema by default, rather than that of the connected user.
Why can't you create another connection with schema containing tables you need?
Why can't you create a connection without specified schema (which will give you access to all schemes the user is authorized to access)?
Related
I'm tired of searching for this, but I couldn't find anything.
I have three databases in SQL Server and although all stored procedures are in the Main database, they work with tables from the other databases.
My question is: if you have the query
select name
from SecondDatabase.dbo.SomeTable
where id = 56
and this query is stored in the main database, will it run in the main database and go all the way to the second database and returns the data, or will it run in the second database and you have the select result directly?
(hope you understand my question)
I think you are misunderstanding the difference between a Database and an Instance.
An instance is the software running the SQL service. Each instance can have multiple databases. For example, there is a master database and a tempdb database for each instance of SQL Server, these are system databases. You can create any number of user databases. All these databases will be handled by the same SQL Server instance (on the same machine).
A particular client session is connected first to an instance and then to a particular database, thats why you include which database you will connect to by default on connection strings (or by login). When you write select name from SecondDatabase.dbo.SomeTable, you are telling the SQL service to retrieve data from the SecondDatabase, even if your session is linked to any other database. The engine will then use your login credential to match a user of the other database (since users go by database and logins by instance) to validate if it has enough privileges to query that table, before searching for the data.
A complete different story would be trying to access data from another instance (machine), in which you will need a linked server, a openrowset or such.
use FirstDatabase
select name
from SecondDatabase.dbo.SomeTable
where id = 56
Question:
will it run in the main database and go all the way to the second
database and returns the data, or will it run in the second database
and you have the select result directly?
Your first assumption is correct:
This query will run in a first database, it will use context and all settings (ANSI, query optimizer and statistic related) of the first database but will get data from a table of the second database.
Just an example from a life: if database have to stay in an old compatibility mode, but new T-SQL features need occasionally to be used, query can switch context to tempdb (which normally set to the latest compatibility level) and run queries referencing data from any other database where access is granted. Usage of those new features will not raise exception
The (now edited) query above will always execute on SecondDatabase.dbo.SomeTable even if the active database context was another database and even if the active user had a different default schema. This is because the object SomeTable is qualified with the schema and the schema owner.
Test to illustrate that the following still returns the executed results (assuming the objects exist and the active user context has access to them)
USE [OtherDatabaseSchema]
GO
SELECT TOP 10 *
FROM [SecondDatabase].[dbo].[SomeTable]
I need our end-users to "clone" a database from our web application UI. I am able to "clone" a database by backing up a source database and restoring it into a new database. In this way, I "clone" the table schema and data.
My question is - is there any way I can "clone" just the table schema, without the data? I am aware that we can script the database manually, and run that script. But our table schema changes frequently (we add new columns and tables regularly) and we wouldn't want to update this script. Thank you.
basically you have to:
save the datatase
restore the backup to a new database (use the with move option)
connect to the new database and then exec sys.sp_MSforeachtable 'truncate table ?'
PS: you may have to disable FK constraints if any.
Antother solution: use Entity Framework Database First to build a small program. Launch said program with a connection string pointing to a new db.
Right Click over database -> Tasks -> Generate Script
On Set Scripting Options page click Advanced
General -> Types of data to script = Schema Only
With SQL Server data tools you can generate the schema difference and apply only the changes to target database.
Due to an error in our build process, we had the following initial situation:
Connection string of the datasource
jdbc:jtds:sqlserver://db01.example.de/AppDB_Example_Prod
Entity files have the catalog "AppDB_Example"
A stored procedure that is called using a named query
{ CALL usp_performSearch(:searchQuery) }
As you can see, we have a missmatch in the connection string and the catalogs. Normally, they must/should be equal.
At runtime, we execute the stored procedure and retrieved the results from the database AppDB_Example_Prod, as this is the database we are connected to. After that, we load related entities using the entityManager from the database AppDB_Example, as this is the catalog mentioned in the annotation of the entity. JPA is doing this itself, we do not have any influence on this.
Searching through the internet, I've read that you should create multiple persistence units / data sources, to work with multiple databases.
Does it work, as it is supposed do do or did we hit a bug?
Could this be used without any problem to work with multiple database via one connection string?
Does this only work with SQLServer (MSSQL) and so it will fail if we may change to an other database in the future?
This feature isn't supported by JPA itself but depends on the database and the permissions of your connection (= usually the DB user which you use to connect).
JPA doesn't care much about the schema. If you don't specify one, then JPA will not send schema information to the database. Usually, there is a default schema attached to the user (or one is specified via the JDBC connection settings). That way, the database knows where to look.
If you specify a schema, then JPA will include this information in the SQL it sends to the database. That means instead of TABLE.COLUMN, it will generate SCHEMA.TABLE.COLUMN. Whether this works depends only on the database (and maybe the JDBC driver) but not on JPA.
All SQL databases should allow you to look at other schemas than the default one if your DB user has the necessary permissions.
I have a question. In SQL server, we can access a table or view in a different database by using the dot notation in the table name, so I believe that in SQL server, if we say just 'tablename' it will refer to the table name in the current active DB, but if we say 'DBname'.'Tablename' you can access the table in a different DB on the same server, and if you say 'serverName'.'DBName'.'tableName' we can access a table in a remote DB whose DBName is defined in a connection setting. I believe we can define a connection setting between two SQL server to access a different database. So, instead of copying the data from one DB to other and duplicate the same, it might be better to simply define a view.
Can anyone please help me if we can do so and how?
Using Linked Server you can access two different servers.
use the below link to add the linked server.
http://sqlserverplanet.com/dba/how-to-add-a-linked-server
I have two databases, one on a remote server the other local. (SQL Server 2008)
The database on my local server has the entire structure setup but no data. I would like to copy the data from the remote server to my server and I am wondering the best method in which to do this.
The main issue I am experiencing is the user that I have to the remote database has limited permissions. I cannot read the stored procedures, user defined functions so when I use Import/Export wizard I do not get the schema etc. So a regular dump/restore is not working for me as it restores the tables without the Primary Keys/Foreign Keys and the stored procedures.
I'd like to do this,
INSERT INTO localtable SELECT * FROM remotedb.table
I was having issues because of the IDENTITY fields and I had to explicitly name all of the columns. Also I am not sure if SQL Server Management Studio allows you to use two different databases, remote and local, so I was looking for any advice.
I have also tried applications like SQL FTP and Backup and it fails because it runs out of memory (I have 16GB of memory on the machine and the DB is like 4GB). I also can use the SQL Server import/export wizard but then I don't get the schema information. I also tried SQL Compare from Red Gate and it runs into issues with the permissions. Unfortunately I do not have the time to request and gain access to a new user so I was hoping someone had a creative idea.
You can definitely use SQL Server Backups for this. It will not run out of memory. If it does please tell us the message (because likely you are misinterpreting it). This is the fastest possible and the most complete solution.
You can tell the export wizard to also script the schema. It is hidden under "advanced" somewhere (terrible UI). But the script will be extremely big and I know of no way to execute it.
You can drop all schema objects except PKs in the target database. Then you can use remote queries to copy all the data over. You will not get any problems with foreign keys and identity columns if you drop the beforehand. After you are done you can recreate all those objects. It is probably best if you use a transaction for all of this because that way you get consistent source data from a point-in-time.