I am very new to EA and in general data engineering. I want to be able syncronize my MS SQL DB with the data model I created in EA. Using the help and tutorials, I learnt how to push my data model onto the MS SQL DB. What I fail to achieve is the syncronization. I have a feeling that is has to do with the schema. The database builder lists all the orginal tables and then again all tables from the ODBC connection with an additional 'dbo.'
Do i need to define this somwhere in the options of my data model or can I compare the data model with the server taking account of the schema?
You need to work in the “Database Builder” feature of Sparx EA.
This can be found on the "Develop" tab. (This will not work directly from the “Browser”)
Select the package having the “Database” as its stereotype. Use mouse button 2 and select “Manage DBMS Options”. The dialog will enable you to change the table(s) owner or even change the selected DBMS type. From the database builder you can then perform the "database compare" or "compare with options".
Note regarding terminology - the "dbo" in SQL Server is a the database owner.
(I have also posted this answer to the Sparx Forum.)
You can find the related documentation with screen images here: https://www.sparxsystems.com/enterprise_architect_user_guide/15.2/model_domains/import_schema_into_builder.html
I needed to add the owner tag dbo to all my tables. For some reson it was not enough to add it to the data model object. Thanks to this thread i found an option to change it for all tables at once.
How do you set the database schema, at the package level, in SPARX Enterprise Architect?
There were still some differences about the PK and FK ids when i tried to compare but I just aligned my local data model with that and now there are no differences between the data model and the data base.
Related
I want to run the SQL Developer database diff feature on schemas different than the schema associated with the SQL Developer connection (my userid).
I log in with my userid but want to use one of the production schema for the comparison. The DBAs control the credentials for the production schemas; my userid can see the production schema objects. We have multiple production databases and want to check for difference in the objects' DDL across the various production schemas.
I tried alter session set current_schema = prod_schema;.
This did not work and the diff report is based on objects under my userid ( I have no objects under my userid in production).
I use the GUI for the "diff wizard" in SQL Developer. No code.
Desired results would list the differences for the production schemas.
Actual results are 0 results since my userid in the production database does not have any objects.
login as SYSTEM (or some other user) for source
On the Objects type screen, select 'Tables'
On the SELECT objects dialog, navigate to the schema where you want to do the compare
Move ALL of the tables over for schema HR
So instead of comparing SYSTEM schema to the target, only those 7 or so tables in HR will be compared to schema connection in the target.
If you don't want to use the schema attached to the target connection, you can use this option
If you say 'Maintain' then the schema attached to the object in the source is used to identify the schema to look in to compare the objects in the destination.
I talk about this more here.
With Jeff's reply, I see that for the SQL Developer Database Diff, in the step 3 of 4 screen dialog, need to select the "More..." option to enable the schema selector list box.
I am using SQL Developer v 18.3.0.277 on Oracle 11r2.
. I have two databases in same azure sql server .i want that both database interact to each other using trigger. i.e If any record is inserted in Customer table of first database the trigger gets fired and record is inserted in another database.
We had / have the same problem with triggers that we use for insert-update-delete where we write a record to Database-1 that has the primary table, but also updates Database-2 where we hold "archive" versions of the tables.
The only solution we have identified and are testing is to bring all of the tables into a single database and separate the different tables under separate database schemas in the one database.
Analysis so far of this approach looks promising.
I think what you're trying to do is not allowed in Sql Azure. From my expertise what you are trying to do is a bad practice on-premise as well (think backups-restore and availability issue scenarios).
You should move the dependency in the application and have the application update both databases, as appropriate.
Anyway, if you want to continue with this approach please take a look over Elastic Query feature: https://learn.microsoft.com/en-in/azure/sql-database/sql-database-elastic-query-overview
Please let me know if I can help with something
I have a lot of views and tables connected in Microsoft SQL Server. I want to check all the useless columns I have in the native tables. Is there a way to perform an automatic check if a column in a table is used or not in other tables?
Create a database diagram in SQL Server Management Studio. From here you can analyze how the tables/columns are related or not. Info here
Do a business model analysis and see which values are used, which are deprecated and start from there.
If you do any changes on the database, these changes have to be projected in any code connecting to that database.
Do not remove columns in tables just by looking at a database diagram. You would destroy any object-relational mapper.
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.
We are in the process of a multi-year project where we're building a new system and a new database to eventually replace the old system and database. The users are using the new and old systems as we're changing them.
The problem we keep running into is when an object in one system is dependent on an object in the other system. We've been using views, but have run into a limitation with one of the technologies (Entity Framework) and are considering other options.
The other option we're looking at right now is replication. My boss isn't excited about the extra maintenance that would cause. So, what other options are there for getting dependent data into the database that needs it?
Update:
The technologies we're using are SQL Server 2008 and Entity Framework. Both databases are within the same sql server instance so linked servers shouldn't be necessary.
The limitation we're facing with Entity Framework is we can't seem to create the relationships between the table-based-entities and the view-based-entities. No relationship can exist in the database between a view and a table, as far as I know, so the edmx diagram can't infer it. And I cannot seem to create the relationship manually without getting errors. It thinks all columns in the view are keys.
If I leave it that way I get an error like this for each column in the view:
Association End key property [...] is
not mapped.
If I try to change the "Entity Key" property to false on the columns that are not the key I get this error:
All the key properties of the
EntitySet [...] must be mapped to all
the key properties [...] of table
viewName.
According to this forum post it sounds like a limitation of the Entity Framework.
Update #2
I should also mention the main limitation of the Entity Framework is that it only supports one database at a time. So we need the old data to appear to be in the new database for the Entity Framework to see it. We only need read access of the old system data in the new system.
You can use linked server queries to leave the data where it is, but connect to it from the other db.
Depending on how up-to-date the data in each db needs to be & if one data source can remain read-only you can:
Use the Database Copy Wizard to create an SSIS package
that you can run periodically as a SQL Agent Task
Use snapshot replication
Create a custom BCP in/out process
to get the data to the other db
Use transactional replication, which
can be near-realtime.
If data needs to be read-write in both database then you can use:
transactional replication with
update subscriptions
merge replication
As you go down the list the amount of work involved in maintaining the solution increases. Using linked server queries will work best if its the right fit for what you're trying to achieve.
EDIT: If they're the same server then as suggested by another user you should be able to access the table with servername.databasename.schema.tablename Looks like it's an entity-framework issues & not a db issue.
I don't know about EntityToSql but I know in LinqToSql you can connect to multiple databases/servers in one .dbml if you prefix the tables with:
ServerName.DatabaseName.SchemaName.TableName
MyServer.MyOldDatabase.dbo.Customers
I have been able to click on a table in the .dbml and copy and paste it into the .dbml of the alternate project prefix the name and set up the relationships and it works... like I said this was in LinqToSql, though have not tried it with EntityToSql. I would give it shot before you go though all the work of replication and such.
If Linq-to-Entities cannot cross DB's then Replication or something that emulates it is the only thing that will work.
For performance purposes you probably want either Merge replication or Transactional with queued (not immediate) updating.
Thanks for the responses. We're going to try adding triggers to the old database tables to insert/update/delete records in the new tables of the new database. This way we can continue to use Entity Framework and also do any data transformations we need.
Once the UI functions move over to the new system for a particular feature, we'll remove the table from the old database and add a view to the old database with the same name that points to the new database table for backwards compatibility.
One thing that I realized needs to happen before we can do this is we have to search all our code and sql for ##Identity and replace it with scope_identity() so the triggers don't mess up the Ids in the old system.