We are using SQL Server Data Tools (SSDT) to manage our customer databases.
In theory all databases are identical, but in practice we have a few stored procedures (and one trigger) that would change from one customer to another.
We created a main SSDT for everything common, and then one SSDT per customer containing only the specific stored procedures (no tables).
In the specific SSDTs we get warnings because SSDT can't find the tables referred in the stored procedures, but we can live with that (obviously SSDT won't be able to validate the table's fields since it can't find the table). For the trigger, we get an error (table can't be found), thus the database project doesn't compile.
How should we manage that? I guess we should not be alone in this situation.
Is there a way for a database project to refer objects (tables) from another database project ?
Thanks,
Yves Forget
Daniel N gave the right direction, I'll just explain. Let's say you have database project named DatabaseA which will contain the only objects that 100% match for every customer. Then you create another database project DatabaseB and include DatabaseA as "the same instance, the same database". In database DatabaseB you can add customer specific objects. Then you can create other database for other customer in a similar way.
IN SSDT you can add another database project or dacpac as a reference.
In the properties for the referenced project you will be able to set where the referenced database resides, same server same database, same server diff database etc
https://msdn.microsoft.com/en-us/library/jj684584%28v=vs.103%29.aspx?f=255&MSPPError=-2147217396
Related
So we have a SQL Server database that is replicated from a 3rd party vendor's cloud down to our local database. Data in the tables is replicated down continuously from their cloud servers and occasionally they update the full database with new changes to structure. Their schema is the default dbo schema.
For reporting, we've added a second schema (let's call it abc) where we add some additional tables as well as some functions/stored procedures that reference the data in both the abc and dbo schemas. I have set up our abc schema in Visual Studio as a database project and it looks great, however, I can't deploy/publish anything because when it builds, it says it can't find tables that are in the dbo schema. Obviously that's just because we haven't created them in our database project because we've only setup the scripts for our abc schema.
Is there a way to tell Visual Studio to either ignore those errors or to look in the actual database (not the database project) for those tables?
You should be able to create a dacpac of the "base" database, then include that as a database reference using "same database, same server"? That would keep the objects out of your project, but allow you to reference them in your code.
In MS SQL Server 2012/oracle, I need to create something like a.b.c
where c is the table/view name, b is the package name and a is the
schema name.
I wanted to create a table/view in two levels. I couldn't find any
proper document regarding this. Any suggestion to find the good document
will be helpful.
MS SQL Server and Oracle are very different. They're both relational DBs, but different vendors and don't function quite the same. There are similarities though.
At any rate, you don't create tables under a package. A table is an object much like a package is an object. A package is designed to hold a collection of procedures/functions within Oracle. SQL Server doesn't even implement packages.
So, as an Oracle example, the best you're going to get is Database > account (or schema..) > table.
I have two database that belongs to two different SQL Server. Their database schema should be very similar but somehow different application generate different 'default schema' on the tables and views. Now when I am trying to compare the schema by using SSDT, I don't know how to ignore this default schema (I found it has a setting but it didn't value, same result showing as treating them as different set of objects).
e.g. Database A vs Database B
[dbuser].[TableA] vs [dbo].[TableA]
SSDT claims they are different..... :S
Please give me some advice... I expect I don't have to hack the database in order to achieve the comparison....
Save yourself the headache get sql-compare from redgate. You shoukd be able to get a trial and test your scenaior. This tool plus their SQL toolbelt is a must for anyone dealing with multiple sql servers. http://www.red-gate.com/products/sql-development/sql-compare/
I have a sql server 2005 database that I want to setup replication for. The problem is that the database has two schemas both of which have a table with the same name in it.
For some reason even though the tables are in different schemas the replication creation fails when done through management studio due to conflicting article names (i assume its trying to create the same name for both tables in the different schemas).
Is there any workaround for doing this in the studio, I can probably write a script or program to do this but just for this one thign is a bit annoying and it probably wont be allowed to run in production.
Perhaps there is a hot fix or something I'm not aware about?
Cheers,
There doesn't appear to be a way around this purely using the new publication wizard in SSMS - the article name is always the table name without a schema-qualifier, and can't be customised from the wizard - although there is a work-around if you use the scripting options.
Go through the wizard as normal, but at the end of the process, untick the "create publication" option and select the "Generate script file..." option.
Once the file is created, open it and edit the article names so that they no longer conflict, then execute the script in the publication database.
could you think of having two publications for your database, each publication being linked to one of the schemas? Of course, this means that you'll have to define two different subscribers, one for each publication. The feasability of this proposal will of course highly depend on how you need to distribute your data among the subscribers, and on the way your users access the data
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.