I have a third party Sql Server data, which I need to use as a data source for my custom database, without duplicating data.
One thing, which comes to mind is to create a View in my custom database, which would reference one or more tables from this third party database.
Is this possible with Sql Server 2014?
Yes, as long as they're on the same server, TSQL: Create a view that accesses multiple databases . If they're on different servers, then you'd have to create a linked server, which I wouldn't suggest unless you're aware of the pitfalls.
Yes very much it is possible but you need to fully qualify the table name like
create view testview
as
select * from db_name.schema_name.table_name
Related
I am attempting to create an indexed view on SQL Server 2008. I have a master database in which I cannot make any changes to (in terms of adding tables, views, etc.). However, I need to create some different views for various reasons that need to work with live data.
I have created a new database along side my master database so I can create views there. I am able to create views just fine, but I want to index some of the larger views. However, when I try to create a schema bound view cross-database, I receive the following error:
Cannot schema bind view 'dbo.Divisions' because name
'master.dbo.hbs_fsdv' is invalid for schema binding. Names must be in
two-part format and an object cannot reference itself.
Since I am going cross-database with the views, I have to reference the name in three-part format.
My creation statement for the view:
CREATE VIEW dbo.Divisions WITH SCHEMABINDING AS
SELECT master.dbo.hbs_fsdv.seq_ AS DivisionID,
master.dbo.hbs_fsdv.fs_division_desc_ AS Description
FROM master.dbo.hbs_fsdv
How can I create an indexed cross-database view in SQL Server?
Plain and simple. You can't. From the MSDN page:
The view must reference only base tables that are in the same database as the view.
https://msdn.microsoft.com/en-us/library/ms191432.aspx
Although (per the docs) it cannot be done directly with a simple SQL statement, this use case is very common and has a solution.
The architecture would have to involve caching the remote tables into your centralized database, and building the indexed view on top of them.
Some good notes on this can be found here:
What is the best way to cache a table from a (SQL) linked server view?
and
https://thomaslarock.com/2013/05/top-3-performance-killers-for-linked-server-queries/
With Entity Framework 4, can I have 2 tables from different db servers in the same model?
I have table X from SQL Server A and Table Y from Server B.
Is it possible to have different connection string per table under one model or do I need to have different dbml files?
No you can't. Whole EDMX file have single connection string. Moreover EF don't allow fully qualified names of tables. Defining table TableA a from linked server MyServer.MyDatabase.dbo will probably in SQL query result in something like [MyServer.MyDatabase.dbo].[TableA] and it will throw exception.
If you want support tables from two servers in a single model, try to link your second server to the first server and create a view for each table from the second server in your current database on the first server.
IIRC you might be able to fully qualify the table name in the DBML if they are linked servers. I don't have anything to test on, I know you can do it in Linq2Sql on Different databases on the same server.
I've got two datasources, one Oracle and one Sql Server. Due to circumstances that predate me (as in it was like this when I found it) some columns in the Oracle database contain PKs from lookup tables in the Sql Server database.
I am attempting to create a Sql Server Reporting Services report that will combine data from both the Oracle and Sql Server database; where the data to be reported is partially from Oracle but some of the values needs to be looked up in Sql Server.
I've got the datasources. I've got the DataSets. I just can't figure out how to show both datasets in the same tabular report.
Is this possible? If so how so? I'd rather not resort to a db link in one or the other databases as I'd like to handle this on the reporting side.
I don't think you can join directly, but you might be able to add a subreport that would query the second datasource by using the foreign key from the first datasource as a parameter. See: How to: Add a Subreport and Parameters (Reporting Services).
You could also try using the Lookup and Lookupset functions within your tablix.
Lookup is a 1 to 1 join while Lookupset is 1 to many and may need you to have your data concatenated if you want a set of strings out.
For Lookup the following is from the MSDN site with some tweaks for my simple mind
Lookup(Field you are joining from, Field you are joining to, Field you want back, Dataset of the field you want back)
The tablix should be linked to the dataset of your source (joining from).
And just realised this is from 2010, not 2014...so a necro-post!
you could also embed a table inside another table and pass the primary key to the embeded table.
You could create a linked server that would contain data from both instances. From the SSRS point of view you would have one single datasource.
You can use heterogenous services or oracle transparent gateway to run the report off the oracle side. Oracle can query the data from the SQL side.
I’m after a bit of advice on the best way to go about this is SQL server 2008R2 express. I have a number of applications that are in separate databases on the same server. They are all “plugins” that use a central staff/structure list that will be in a separate database. The application is in the process of being migrated from JET.
What I’m looking for is the best way of all the “plugin” databases being able to see the central database and use those tables in standard queries and views etc.
As I’m using express that rules out any replication solution and so far the only option I can think of is to use triggers or a stored procedure to “push” out all the changes to the plugins. The information needs to be populated on a near enough real time basis however the number of changes will be very small maybe up to 100 a day and the biggest table only has about 1000 rows at the moment (the staff names table).
Hopefully that will cover all everything but if anyone needs any more details then just ask
Thanks
Apologies if I've misunderstood, but from your description it sounds like all these databases are hosted on the same instance of SQL Server - it's your mention of replication that makes me uncertain.
Assuming that's the case, you should be able to replace any copies of tables from the central database which are held in the "plugin" databases with views or synonyms which reference the central tables directly, since SQL server allows you to make references between databases on the same server using three-part naming (database_name.schema_name.object_name)
For example, if each plugin db has a table StaffNames, you could replace this with a view by dropping the table, then creating a view:
drop table StaffNames
go
create view StaffNames
as
select * from <centraldbname>.<schema - probably dbo>.StaffNames
go
and your code should continue to work seamlessly, as long as permissions are set up.
Alternatively, you could replace all the references to the shared tables in the plugin databases with three-part name references to the central database, but the view method requires less work.
I have a couple of questions.
1) Why cannot we see system tables (like sysobjects) under Master/Model/MSBD etc.? But we
can query. Are we basically querying the views, because as they are the main tables that
holds a value able informations?
Like "SELECT * FROM sysobjects". are we basically querying some views?
2) Why cannot we add triggers to system tables?
Thanks in advance
SQL Server 2008 system tables (http://msdn.microsoft.com/en-us/library/ms179932.aspx) have been implemented as read-only views. One cannot directly work with the data in these system tables. You can access SQL Server metadata using catalog views. Do check this link http://msdn.microsoft.com/en-us/library/ms174365.aspx
It is possible to create triggers on system tables but it is generally not recommended. Please check this http://www.sql-server-performance.com/faq/trigger_system_table_p1.aspx
cheers
Since SQL 2005 the catalog views are implemented as views declared in the Resource Database (mssqlsystemresource). Due to some special magic they appear to exist in every database.
You can always use the execution plan to see from what actual tables do these views fetch data from. The underlying tables can be accessed when you are connected with a DAC connection. Modifying the system tables in any way will mark the database and an message will be logged every time the database starts up. Modified databases are not supported by MS, so if something goes wrong you cannot ask for support.