I have a table that has 1K rows. In the table there is a column that has the names of the customers. I need to add a column that counts (index) how many customers I have.
Doing a calculated measure using the distinctcount formula I get 3156 customers. My goal is to accomplish the same result of the calculated field in a calculated column.
Thanks for the help.
Not sure about a calculated column but one way you can accomplish this is to make related dCustomers dimension table from your source. You question didn't happen to mention your source - here is how I'd do it for the most common sources in my estimation:
SQL database connection:
SELECT DISTINCT customerField
FROM yourViewOrTable
Excel/Text File:
Duplicate the worksheet with the Linked Table.
On the worksheet copy delete all columns except the Customers column.
With the a single cell active in the data go to Data>Remove Duplicates.
Under the PowerPivot ribbon tab click Create Linked Table.
Now What?
You should now have two tables from whatever source you are using. You'll find your new table has 3156 records in it. Go to Diagram view and drag a relationship from table1.CustomerField to table2.CustomerField.
With the relationship made you should be able to do anything you need to do, but please fire back if you have any questions on your use case.
Related
I have two data providers. One is a universe, one is an excel file. Excel file has column ID. I want to find ID,JOB_ID, Cost
I have created a merged dimension:- ID. When I create report with ID and Cost, I'm getting an outer joined result which is what I want. But when I add another attribute from universe it is being inner joined result. Where can I control this feature
You are ever so close. Here are the basics when working with a zero or one to many relationships. Credit for this goes to this blog post. I am copying it here if perchance that link goes dead.
As a rule of thumb , when trying to merge DP’s with a 1xN relationship
:
Merge the common fields
Use the dimension coming from the N side query
Create detail variables from the 1 side query for each dimension needed with associated dimension equal the merged dimension
Check "Show rows with empty dimension values" on Table formatting for each table using dimensions coming from both queries.
Here is a screen shot to highlight where to find the setting in step #4.
I am developing an application for making quotations. First you make cost break down (or calculation) and upon that result you add item to quotation. The problem is that i have many product, so each category of a product will have its own cost break down form with different parameters to be filled in. If I will have only one table for cost breakdown, then it will be huge (a lot of fields in table). I have a feeling that this is not the right approach. So I came up with diagram below:
Is this solution even possible, or I must have "N" (if I have N-tables) different FK for each cost break down table? Do you have any better solutions?
I have another question if my linking table "Quotation_QtnDetail" is necessary?
It would be possible to store a reference to a particular value in one of these tables by having a CalculationType column indicating which table the record is in, along with a generic reference ID column (containing the ID of the relevant record). For example, if you were storing a CalcId of 123 and a CalculationType of 2, this would point to the record with ID 123 in the Calc2 table.
The downside to doing this is you're going to lose the ability to validate your data using FK constraints, and it will also make joins to your calculation tables a bit more complicated.
Regarding the Quotation_QtnDetail table, unless a QtnDetail record could ever be linked to multiple Quotation records, there is no need for this extra linking table. Instead, just link it directly by adding a QtnId column to the QtnDetail table. Similarly, you may also be able to remove the Calc_QtnItm table if an item is only ever linked to a single calculation record.
I have few tables to store company information in my database, but I want to focus on two of them. One table, Company, contains CompanyID, which is autoincremented, and some other columns that are irrelevant for now. The problem is that companies use different versions of names (e.g. IBM vs. International Business Machines) and I want/need to store them all for futher use, so I can't keep names in Company table. Therefore I have another table, CompanyName that uses CompanyID as a foreign key (it's one-to-many relation).
Now, I need to import some new companies, and I have names only. Therefore I want to add them to CompanyName table, but create new records in Company table immediately, so I can put right CompanyID in CompanyName table.
Is it possible with one query? How to approach this problem properly? Do I need to go as far as writing VBA procedure to add records one by one?
I searched Stack and other websites, but I didn't find any solution for my problem, and I can't figure it out myself. I guess it could be done with form and subform, but ultimately I want to put all my queries in macro, so data import would be done automatically.
I'm not database expert, so maybe I just designed it badly, but I didn't figure out another way to cleanly store multiple names of the same entity.
The table structure you setup appears to be a good way to do this. But there's not a way to insert records into both tables at the same time. One option is to write two queries to insert records into Company and then CompanyName. After inserting records into Company you will need to create a query that joins from the source table to the Company table joining it on a field that uniquely defines the record beside the autoincrement key. That will allow you to get the key field from Company for use when you insert into CompanyName.
The other option, is to write some VBA code to loop through the source data inserting records into both. The would be preferable since it should be more reliable.
Consider the following situation:
In my database: Table "Items" => Several thousand records, 35 columns.
Linked server: View "ItemInfo" => Several thousand records, 45 columns.
1 column in both ("ItemID") provides the matching key between table and view (Unique, not NULL in both.)
30 columns (not counting ItemID) appear on both sides, but may be of different type. E.g, in view ItemInfo it is a date or number field, while in table Items has a string containing a date or number. This happens on about half of the columns.
Table and view content do not exactly match.
About 99% of the rows appear in both with matching ItemID (but the other columns may have different values). The other 1% only appears on one side.
I need a stored procedure (in the database containing table Items) to update the table Items, so that that values from the view ItemInfo are copied in the table. (For a matching row the values from the view are leading.)
Additionally: In case a rows doesn't exist in table Items, it must be copied from view ItemInfo. Extras in the table (not present in the view) can be left as is.
I need to synchronize the table with the view several times a day, but the number of mutations (each synchronization) will be very low. Possibly none. I have no way to tell if a entry in the view is actually "new" or "updated".
My current proposed solution is to do this in 2 steps:
for rows in view ItemInfo that have no match in table Items insert that row in table Items, using a sub-expression for each column (if needed) to do type-conversion.
run an update over table Items updating each column (with a sub-expression) with the corresponding value from the matching entry (if existing) from view ItemInfo.
Step 2 is obviously very in-efficient, because there is no need to update the vast majority of the rows.
Only a handful (if any) will actually have been changed since the last update.
The whole thing involves a bloody mess of sub-expressions, but I don't see any other approach.
Can someone think of a better idea to implement something like this?
To clarify:
I'm not looking for an complete solution to my problem, but more for a general approach to take on similar problems.
I'm certain I'm going to face this multiple times over the coming years...
P.S.
I have no control over the view. Just read-only access to read it. I do have full control of the database where table is located, but I can't change anything about the structure of table Items itself, because there is other software interfacing with this table over which I have no control. I'm free to add temporary tables if needed.
I have a table "Members" and a table "Books". To one member can belong many books but one book can belong to only one member, so I create a many to one relationship. I created an intermediate table "Owners".
I will put in the form "f_Members" a subform "f_Books" and in this I want to have for a field a lookup column with the list of all books. Now, for the first member I will choose let's say book1 and book2, then for the second member I want in the subform in the lookup column to be listed all books but with book1 and book2 greyed out and not possible to choose them anymore.
Is this possible in access 2007? Thank you in advance.
First of all, as a Many-To-One relationship, you do not need an intermediate table, rather add a Foreign Key in the Books table, refering to the Members' Primary Key.
It might be a bit more code for you to do this, but I would consider the following:
In f_Books, assign the recordset to be the [Books] table.
If you desire to show the already selected books grayed out, that would be easy to do with Conditional Formatting (see here), with an expression like Nz([books_fk_member_id]) <> ''.
You can add a second condition to color the books already selected by this member with an expression like Nz([books_fk_member_id]) = [Forms]![f_Members]![control_showing_member_id].
To make them not choosable, I think that the [Enabled] check button might do the trick for you, or you can write some code in vba, refering to [Forms]![f_Members]![Form]![f_Books]![books_fk_member_id] in order to identify the books' owner.
All that, given the fact that you choose to eliminate that extra table. If you don't the logic is the same, you just will have to use more complex conditions to get the same result.
Hope I helped.