Actually, I would be satisfied just getting to pick the direction of the one-to-many. I have one table, the result of a SQL query that I want to use as a lookup table. It is unique in its key column, but I don't know how to tell Powerpivot that. I have another table which is linked from Excel where the user can type in a key to look up stuff in the big table. When I use diagram view to connect these tables, it creates a many-to-one relationship in the wrong direction and then RELATED('lookuptable'[key value]) fails. There is really a one-to-one relationship between the one row supplied by the user and some row in the big table. How do I convince PowerPivot of this? The version I am using is 2016.
You can change which is the lookup/1-side table and which is the many-side, either by clicking and dragging from the many to the one, or by switching the tables in the edit relationship dialog.
Coming eventually for 2016, likely no later than the GA release of SQL Server 2016, is the concept of a bi-directional relationship in which filter will flow both ways between the tables in a relationship, and hopefully many-to-many support natively along with that.
Edit:
In the Create Relationship dialog menu, whichever table you define on the left will become the many side of the relationship, so you can simply create the relationship through this dialog.
That being said, I have confirmed that when defining a relationship in Excel 2016 by clicking and dragging fields, the field that you drag becomes the many side of the relationship, and the field that you drop on becomes the one side of the relationship. The arrow points in the direction that filter context will flow (note that this is the opposite direction of the lookup arrows in previous versions of Power Pivot). Filter context follows the arrow, but calls to RELATED() or RELATEDTABLE() go in the opposite direction of the relationship arrow. You can only call one of the RELATED*() functions from the table that the arrow points to. If you need to reverse the relationship, just delete and redefine it by dragging from the other table.
To modify the relationship in the Edit Relationship dialog menu, you will need at least three tables in the model, and you will then need to juggle the tables, using the third table to allow selection of the first two appropriately.
Edit 2:
It turns out that the edit relationships dialog launched by Relationships in the pivot table Analyze ribbon menu does not behave in the same way as the Power Pivot dialog, and so the following works to switch relationship direction regardless of how many tables are in your model. Table is the many side, Related Lookup Table is the one side.
One to one relationship is currently not supported in Power Pivot for Excel. It looks like it is only supported in Power BI.
See links:
https://exceleratorbi.com.au/relationships-power-bi-power-pivot/
https://social.msdn.microsoft.com/Forums/en-US/9aafb848-8853-40a5-b91f-f6094779c99e/onetoone-relationship-not-working?forum=sqlkjpowerpivotforexcel
Related
I'm trying to convert a data model that uses composite keys, but I know as of version 9.14 Directus doesn't support them. I use these keys to offer clients different items from the same table. To get around this limitation, I'm using M2M relationships that offers each client the same options:
The junction table just stores the keys to save the relationships. Is there a way to add another column from the related collection in the admin panel to define what the key represents? This would help clients understand what values are assigned.
Also these M2M relationships are options to be selected in new collections. Is it possible to use a M2M relationship in a Select Box to force only one option to be selected?
Lastly, is it possible to filter all collection items based on a client ID associated with a login ID? This would allow one data model to support multiple clients. Is it possible to use SQL queries to populate collections displayed in the admin panel?
Thanks in advance for any help and direction.
Thanks,
Brandon
I'm new to CDS/Dataverse, coming from the SQL Server world. I created a new Dataverse table and there are over a dozen columns in my "new" table (e.g. "status", "version number"). Apparently these are added automatically. Why is this?
Also, there doesn't seem to be a way to view a grid of data (like I can with SQL Server) for quick review/modification of the data. Is there a way to view data visually like this?
Any tips for a new user, coming from SQL Server, would be appreciated. Thanks.
Edit: clarified the main question with examples (column names). (thanks David)
I am also new to CDS/Dataverse, so the following is a limited understanding from what I have explored so far.
The idea behind Dataverse is that it gives you a pre-built schema that follows best-practice for you build off of, so that you spend less time worrying about building a comprehensive data schema, creating tables, and how to relate them all together, and more time building applications in Power Apps.
For example, amongst the several dozen tables it generates from the get-go is Account and Contact. The former is for organisational entities and the latter is for single-person entities. You can go straight into adding your user records in one of these tables and take advantage of bits of Power Apps functionality already hooked up to these tables. You do not have to spend time thinking up column names, creating the table, making sure it hooks up to all the other Dataverse tables, testing whether the Power Apps functionality works with it correctly etc.
It is much the same story with the automatically generated columns for new tables: they are all there to maintain a best-practice schema and functionality for Power Apps. For example, the extra columns give you good auditing with the data you add, including when a row was created, modified, who created the row etc. The important thing is to start from what you want to build, and not get too caught up in the extra tables/columns. After a bit of research, you'll probably find you can utilise some more tables/columns in your design.
Viewing and adding data is very tedious -- it seems to take 5 clicks and several seconds to load the bit of data you want, which is eons in comparison to doing it in SQL Server. I believe it is how it is due to Microsoft's attempt to make it "user friendly".
Anyhow, the standard way to view data, starting from the main Power Apps view is:
From the right-hand side pane, click Data
Click Tables
From the list of tables, click your table
Along the top row, click Data
There is an alternative method that allows you to view the Dataverse tables in SSMS – see link below:
https://www.strategy365.co.uk/using-sql-to-query-the-common-data-service/
To import data in bulk:
Click on Data from the top drop-down menu > Get data.
Importing data from Excel is free. To import from other sources, including SQL Server, I believe is a paid service (although I think you may be able to do this on the free Community Plan).
We have an in-house program at the company I work for, and inside of MS Access we link all of our tables to our three databases. However; in order to create new routes for students, someone needs an isolated copy of our program to work with that won't impact the actual database.
After deleting the linked tables, importing them all locally, and saving the .mdb I can no longer change values inside of most forms. For example:
A drop down menu with a list of possible route codes for a student will appear. Usually you can select one. You are no longer able to, and in the bottom left hand corner you see "this recordset is not updateable".
I'm a bit new at this, but I can't imagine why importing the tables would break anything. I wouldn't expect any key violations to occur (like I might when linking tables), or anything of that nature. If anyone can point me in the right direction it would be much appreciated! Thanks!
Access can handle a compound primary key on a linked table or view. The important thing, of course, is to make sure you're telling Access the right fields to use. It's common for Access not to get the primary key info when you're linking to a view (perhaps the ODBC driver doesn't pass that info along?), but I bet it can happen with tables too.
Not sure if these pics will help, but hopefully it can point you in the right direction. Here's a linked view, as you can see in this picture:
If you open it in design view, you can see that there are no primary keys:
which means that the table isn't editable (the add new button is greyed out):
So I run this command to tell Access to use a compound primary key on the linked view:
CurrentDb.Execute "Create Unique Index PrimaryKey On View_AssnsWithSorterField([Serial No], AssignmentDate)"
If you open the linked view in design view again, you can see the compound primary key:
and now the add new button appears.
You said that you tried to add a compound primary key but Access wouldn't allow it, which sounds like there's something about the table's data or structure that prevents it from using that key. How about creating an empty copy of the table in the backend database, then try linking to that? If that still doesn't work then maybe there's a unique constraint, or a trigger, or something else on the table that causes Access not to like making it updateable. Conversely, if it links fine and you can add/edit records in the linked blank test table, then it must be data in the real table that's causing the issue.
Sometimes if you cut down a copy of the table into smaller chunks (like maybe just start with the primary key columns alone) and gradually rebuild it piece by piece, you eventually hit on the thing that makes Access not let it be updateable.
One other possibility, of course, is a problem with the driver itself. The ODBC drivers that link to SQLServer and Oracle are good quality and can handle complex primary keys, but I've used junky drivers that link to obscure databases and they couldn't handle complex things like subqueries, union queries, etc, even though you could do those things in the database itself; the driver was only written to handle basic select/insert/update/deletes and that was it.
BizAgi tables are used to view collections in 1-m relationships.
It is also possible to view m-m relationships from the point of view of one entity (thus, a 1-m relationship).
The add and delete buttons don't work with m-m relationships and no errors appear.
Has anybody used them successfully?
My interpretation with an example:
One contract has N clients, and one client has N different contracts. You want to use collections to represent this connection.
The only was I see of representing this information is to have a table of contracts, to which the edit/detail form shows a table of clients for that contract.
You might also want to consider using a form link as a column of that table.
Let me know if this is a correct interpretation.
I've not really used access for a while and not too sure how best to proceed with this data model:
I have set of resource tables of differing type, eg: Data, Literature, Contractors, etc.
I also have a set of category tables such as Procedures, Topics, and Regions.
I need to create many-to-many relationships between the various resources and the various categories so it is possible to view a resource record and see lists of the various categories to which the resource is allocated, and vice-versa, that is to view all resources allocated to a specific category.
I realise that I could create lots of link tables, eg: LnkDataProcs, LnkDataTopics, etc, however with perhaps 10 resource tables and 3 category tables I would wind up with 30-odd link tables which seems wrong (it may also be useful to query all resources from each category anyway so it would be good to have one link table for each category).
I've done this kind of thing before using SQL in custom DB client apps by using one link table with fields as follows: CategoryTable, CategoryID, ResourceTable, ResourceID - So that the link table stores the table name as well as the foreign key.
However I'm not too sure how to fit this kind of model into an access database, it would be nice to use the Access framework (master-child form objects) rather than having to write loads of custom code to perform queries and populate forms.
Any ideas how to proceed, or even what this kind of relationship is called?