I have one table.
I have to make attributes only from the fields on that table.
I have to use these attributes on one report.
I wanted to ask that all the attributes I have made are keys. Is this fine? If not, how do I resolve this issue?
The Keys are like primary, foreign keys in RDBMS. They define the joins
So long as you do not have other tables involved in the design, this is fine.
Ideally attributes are made only for dimensions
e.g
you could make attribute called Issue with forms(Issue id, Issue desc, Issue date) with Issue id as the ID form that drives the join with the other tables
All attributes should not be keys. Every key denotes that the tool is interpreting them as primary keys. Set proper relationship (parent-child) between the attributes and you will see keys only for the child attribute(s).
Related
I have a query with EF which looks like this:
var x = _db.qMetaDataLookups.ToList();
if I execute, direct on the SQL server SELECT * FROM qMetaDataLookup, 2155 distinct rows are returned. After executing the above, x ALSO contains 2155 elements.
The problem is that the data is wrong. I'm not getting the same data back from the EF as I do from the SQL Query.
In particular, theres a particular element that exists on the SQL output, call it "WXYZ", which makes no appearance at all in the EF version of the query (against the exact same database).
Instead, what I find are numerous repeats. If I call x.Distinct() the list filters down from 2155 elements, to a mere 143.
I'm flummoxed. I have never seen my EF and SQL results differ on a query this simple. There must be a very simple [face-palm] explanation, but I'm missing it.
Thanks.
EDIT qMetaDataLookup (a view) are contains information about our database. In essence, its a listing of all tables and views, and each of their columns, with other information about the datatype, length, precision, scale, etc. The 'key' in this table ought to be the column that matches "tableName.columnName" but instead EF chose for it all the datatype properties. This is why the query fails to perform as desired.
Make sure the entity key is set correctly for qMetaDataLookup in the Entity Data Model. Sometimes the entity keys are messed up...
The issue might have been that your model was using a key with duplicate values where the Entity Framework was expecting unique values. This would happen if, for example, your data model used a composite primary key composed of foreign keys from other tables. It seems EF doesn't like composite primary keys very much, and so returned results from queries will generate what appear to be duplicated rows.
The fix seems to be to add a surrogate primary key column to your table which is guaranteed to be unique. If you still need to reference the foreign columns that's fine, so long as they aren't being used as a composite primary key for the table.
I can't claim any credit for the solution, but here's the link that helped me solve my issue:
http://jepsonsblog.blogspot.ca/2011/11/enitity-framework-duplicate-rows-in.html
I'm using entity framework 4.3 model first and can't figure out why I'm not allowed to have a one to zero-to-one association along with a referential constraint.
I have two main problems. I can't force referential integrity (without manual intervention) and my lazy loading doesn't seem to work... all my 1 to many associations are fine.
I basically have two tables, Loans and Contracts. The Contracts table has a scalar field for LoanId.
Until a loan is submitted, it does not have contract data and I chose not to place everything in the same table due to the size of the contract data. Ie. I don't want contract data retrieved from the database unless it is actually required.
I've searched around and can't seem to find any model first information that clearly answers my questions. Any information that may help me understand and clarify my problem would be greatly appreciated.
Regards
Craig
I guess LoanId field is not a primary key in Contracts table. In such case you cannot have such one-to-one relation because EF doesn't support it. When you create LoanId field in Contracts table the only way to force one-to-one relation is to add unique constraint on that field. EF currently doesn't support unique keys (except primary keys) so the only way to create one-to-one relation is to create relation between primary keys (Loan.Id <-> Contract.Id). If you don't follow this you will get error in designer.
I have 3 tables:
1. Invoice
InvoiceID int PRIMARY KEY
2. Order
OrderID int PRIMARY KEY
3. Transaction
TransactionID int PRIMARY KEY
Source int
Category string
On table "Transaction", Source (unfortunately) is behaving as a "polymorphic"(??) foreign key (there must be an actual term for that - sorry for my ignorance) that depending on the Category column it'll contain the ID of Invoice or Order.
However there's no actual foreign key.
Using EF 4.1 code first, anyone has any idea how I would create the proper associations?
Help is appreciated!
Thanks
Solution
Uh... Embarrassment is kicking in... I can just map it same way regardless of any actual DB foreign key.
I was having problems while trying to do that but basically wasn't related to this. I had computation properties that I didn't ask the context to ignore which was generating wrong queries.
You probably should create two nullable FKs instead of weak reference like that.
Uh... Embarrassment is kicking in... I can just map it same way regardless of any actual DB foreign key.
I was having problems while trying to do that but basically wasn't related to this. I had computation properties that I didn't ask the context to ignore which was generating wrong queries.
I'm getting more and more frustrated with EF...
I have a table called ExtendedField with:
Record
DocRef
DocType
Name
Record is the primary key
DocRef and DocType are foreign keys used to identify which Ticket they belong to
Name is the key used by the "definition" table to define what the field actually is
So basically I need 2 associations:
One between Ticket and ExtendedField
on ExtendedField.DocRef=ticket.record
and
ExtendedField.docType=HeaderDocType
One between Definition on
ExtendedField.Name=Definition.FieldName
Then I still need Record to be the primary key so I can directly access the fields.
As near as I can tell this is impossible to do in Entity Framework. For every association all the keys need to be mapped together, whereas I need two keys for one association, 1 key for another one and the actual primary key wouldn't be used in any associations.
It doesn't appear that you can define an association between fields that aren't entity keys either.
So is there any way to do this? Am I missing something?
It's a v1, bro. I myself have had some major pain with mapping of key constraints in EF. I hear that better things are coming in v2.
I have the following tables in the database (just a demo, of course):
Positions
PositionId
Limits
LimitId
PositionId
I want to left join them into a single entity (always have position, not always have a limit attached to it):
Position
PositionId
LimitId
I've seen articles regarding one-to-one mapping and "Table per type inheritence", and tried to implement the same method here, but with no sucess. Is that even possible?
I think what you want is an ordinary inner join where your foreign key (PositionID in the Limits table) is allowed to be null.
Yes and no...In my scenario, the 2nd option is the applicable one, since I don't have the same primary key in both tables. so, I must create an updateable view...The problem with updateable view is that I can't modify fields which are in different tables and expect the database to handle it, unless I use "Instead of" triggers, which I really don't want to get into at all...
So, I guess there's nothing out of the box for me...damn.
(Unless you have another idea...)
Anyways, I really thank you for your help, it's much appreciated.
Nir.