I've got two databases: one called db1 and the other one called db2. I've got two models, School and SchoolProd. I want SchoolProd to connect to db2, but to also recognize "schools" as its associated table. I achieve this by doing
establish_connection :db2
set_table_name 'schools'
When I run the rails console, and ask for SchoolProd.all, it gives me all objects from the schools table in db2, but when I try SchoolProd.all again, it gives me all objects from the schools table in db1, not db2. Why is this happening? The first query I do behaves as expected, but the rest is done in db1. Thanks
Ok, I found out why I was getting this error. Turns out I had the ar-octopus gem in my Gemfile. This gem provides Database Sharding in ActiveRecord. I decided not to use it, but forgot to remove it from my Gemfile. Once I removed it, everything went fine
Related
I last looked at Schemas (on Oracle) about 20 years ago, I know that Microsoft changed schemas in SQL Server 2005. We're now about to create a new application and I've long wanted to take another look at schemas.
We use 1 specific login to do the applications work so it has db_owner role and 1 specific login for running all reports so it has data_reader role.
I've done my research as well as poked around and wrote some scripts. This script "appears" to be all I need in order to create a schema:
CREATE SCHEMA [MySchema];
I used the sa user to create the schema and related tables. From there, I've been able to create tables within the schema and access them just fine from the two users.
My question is, was this very simple statement all that there is required to create a schema "correctly" and are there any specifics I should be watching out for?
We already access all db objects with the [dbo]. schema prefix in preparation for going multi-schema. I'm just not sure if there's something sneaky when we finally start getting into stored procedures, functions, views, indexes, foreign keys and the likes. So far all my testing has come up roses but I'm concerned I'm missing something that's going to really beat me with a stick some ways down the line.
. 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
With the command-line option, I tried to do the multiple-schemas thing: have a gold schema with the metadata table, and a series of user sandboxes slaved to it.
flyway -schemas=SCHEMA1,SCHEMA2 clean
This worked OK. All the schemas were wiped.
flyway -schemas=SCHEMA1,SCHEMA2 init
This worked OK, or at least as I expected: only created metadata table in the first schema.
flyway -schemas=SCHEMA1,SCHEMA2 migrate
This did not work - only migrated the first schema, subsequent were ignored.
Is this broken in 2.1.1? This seems like the basic point of having multiple schemas.
I've stumbled across some odd T-SQL code in SQL Server 2005, which I'm trying to understand how it could work.
If there are two tables called tblScenario in two separate schemas, one is in Cache schema and the other is in Dimension schema.
What would we expect to find when we query SELECT * FROM dbo.tblScenario? How does dbo map to one of these schemas in a reliable and predicable way?
For some reason this actually works however we don't know why?
We are going to fix it so it is explicitly calling SELECT * FROM Dimension.tblScenario, but I was curious.
Thanks,
Philip
OLTP Check...
1) is DBO.tblScenario a view?
Othewise, it sounds like you're dealing with SQL Server Analysis Services (SSAS), which deals with dimensions, mimicing tables, etc. More info: http://technet.microsoft.com/en-us/library/cc966452.aspx
If you are running the old version of the query in the Dimension schema I would expect it to return data from the Dimension schema, if you are running it in the Cache schema I would expect it to return data from the Cache schema, and if you are running it from any other schema I would expect it to return an error (similar to that recorded by Chris Diver).
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.