Whenever I have two tables in the same column, I get this error.
Create a table in columns (ie B1:C3)
Create another table below that table (ie B5:C7)
Right-click on column B
Is the "Delete" option grayed out (unavailable)?
Convert the second table (B5:C7) back to a normal area
Right-click on column B
Is the "Delete" option active (black) now?
It is for me.
I don't understand why it happens but I'd really appreciate if someone could confirm that I'm not alone on this one. This actually seems like a bug.
Unfortunately this is 'behavior by design'. A ListObject (aka structured ) table has many internal mechanisms. The Delete (column) command is not designed to enumerate through all of the ListObjects on the worksheet to see if any intersect with the column being deleted and then spawn subprocesses that deal with deleting table columns specifically while simultaneously keeping in mind how that will affect other ListObject tables. Instead, it simply does not allow the Delete command when more than a single ListObject table is involved.
This is not allowed may be because deleting a column will Shift Cells Why Dont you try deleting by selecting one column of a Table Like this
see the screenshot you can do it if you select one column of a table at a time
Thanks
Try organizing your data in a different way, so these problems don't occur.
There is no compelling reason to have several tables on ONE sheet. If table placement presents a problem with row/column management, consider moving tables to separate sheets.
Tables can be referenced in formulas by the table name. Ditto for table columns, so there really is no reason to keep several tables on one sheet if you need flexibility with row and column management.
Edit after comment The fact that users are working with several tables and cannot be expected to change sheets to maintain data on different sheets can be addressed in different ways:
Educate your user. I'm a big fan of teaching people how to use software. If they understand what they are doing, they feel positive. If you keep them dumb and tell them to "just click there and shut up" they may feel negative.
You may want to re-consider your data architecture. Provide your users with an interface to add/edit/delete records that is independent of where the data is stored. This is 2016. Data input and data storage are not married to the same page.
You are posting your question in a site for enthusiast programmers. A little bit of VBA will separate your data entry/data storage issues, if you are interested to work it out.
Related
I am trying to create a simple pivot table which will tell me how many community residents reported a particular problem, and what percentage of them reported each problem type. I have a data set with name, and then columns for each type of problem. Here's an small sample of the data set:
I have created a pivot table which sums each of these columns and also provides me the total number of people who reported any type of problem at all. Here's what I have:
I want to add a second column to this pivot table that gives the percent of times each problem type was reported. Sounds simple, but because of the structure of the original data set, I can't figure out how to do it. I can set up formulas outside of the Pivot Table which reference the table, but in doing so I forfeit the ability to graph the percentages on a pivot chart. Any ideas how to create a calculated field for this pivot table?
Just to be clear, what I want is something like this, except all contained in the structure of the pivot table:
Edit: I've changed the example of the data set. Here's an explanation of the pivot table. The values under the "# Reporting Issue" column are counts of all the 1's under each corresponding column in the data set. This meant that I had to add each row to the pivot table independently, as you can see here:
I'm open to the idea that I need to change the formatting of the data set, but I'm not sure of the best way to do it. This was set up initially because it allowed for easy compilation into a data table, but Pivot Tables seem to be a different story.
Hopefully this edit clarifies things.
You need to unpivot your data so that you turn it into a Flat File...something that the PivotTable can consume properly.
The easiest way is to use something called PowerQuery, which is baked in to Excel 2016 but available as a free addin from Microsoft for any other versions. Google PowerQuery Unpivot and you will turn up hundreds of tutorials, such as this one from my good pal Chandoo . PowerQuery looks slightly daunting at first to a first time user, but it is freakin easy once you get your head around how to use it. PQ is by far the best addition to Excel in years. PowerPivot being a close second.
If you can't install PowerQuery, then you can use your current data structure to make a 'staging pivot', and then drag the Values label that will appear in the Columns area to the bottom of the ROWS pane, like in this excerpt from a book I'm writing:
Note that my Year categories are equivalent to your Issues categories.
That will emulate the flat file layout you’re after. All you need to do then is turn this intermediate PivotTable back into a normal range, change that Values heading to Issue, and add a Count heading and you’ve got the flat file you need to build a useable PivotTable.
You can also use VBA. Google Unpivot VBA and turn up hundreds of results, including this blazingly fast code I posted some time back. (Look for the code under the —Update 26 November 2013— heading.)
You can also use the DoubleClick extraction trick.
I have prepared a master Excel file which pulls data by means of a Power Query from several smaller Excel worksheets, all containing the same set of data (same columns) - one per employee.
Today I noticed that for some employees, some of the data is duplicated in the master table, even though said duplicates do not exist in their separate worksheets.
The master query is made up of separate "Connection Only" queries, pointing to each individual file. Regardless of how many times I click Refresh All, Manage Data Model, the duplicates still stay there.
Has anyone encountered anything similar or would you have any ideas what could be the reason behind this and how to get it sorted out?
Thank you!
You havent really provided enough info about your design, but I'm guessing you are using Merge Query steps to combine the "smaller Excel worksheets" ? If so then the typical issue is that you have not specified the correct columns to match on in the Merge Queries Step definition.
If the combination of columns you have chosen on at least one side of the Merge are not unique, then duplicated rows will appear on the subsequent Expand step.
The way to find these is to start a new Query against each source table in turn, select the columns you are matching on and use Keep Rows / Keep Duplicates. You should see no rows resulting - any rows that do appear are the source of your duplicates.
I usually save such queries and include them in the Refresh as an automated test going forwards. I put them in a separate Query Group e.g. "Tests - should return 0 rows".
I thought there would be a simple way of doing this, but unfortunately I have not come across one. My company has an Excel workbook with 12 sheets (1 for each month), into which I enter sales data as accounts are written. I reformatted each month's data into tables, thinking that this would provide an easy reference to gather the data into a pivot table that joins all the months and would be updated as I enter data; however, a pivot table based on multiple sets of data allows highly limited manipulation.
So what I want to do is create a new table that is automatically populated as I enter data in any of the 12 current tables, to combine them into a master listing. I have tried doing a query, but when I try to set up the data sources, it doesn't recognize my tables. I tried Power Query, but I couldn't get it to update the data as I updated the source. Consolidate also was not a useful feature, as it required all the data to be somehow calculated, and my columns need to simply be copied over, not summed or averaged.
As you can probably tell from my explanations and terminology, I'm no Excel expert. I don't know what VBA even is, let alone know how to use it, but I've seen it mentioned a lot, so I figure at some point in my life I should learn it.
Is there a formula or some other Excel 2010 feature that can automatically copy all of this data onto one running list, and keep it updating as I enter data in the source tables? It would have to run automatically.
I believe your end goal is to have a pivot table which consolidates data from each of the individual 12 sheets/tables and not really to have the intermediate "single running list which is an aggregation of all the 12 sheets".
If so, I suggest to create an Excel Pivot table directly based upon the 'Multiple consolidation ranges'.
To start, create a new spreadsheet and select a cell (say A3) and use the click sequence Alt+D+P, this will bring up the PivotTable and PivotChart Wizard, and proceed further using the third option - 'Mulitple consolidation ranges'.
I will have to refer you to the below site for a detailed step by step instructions on the above: http://www.contextures.com/xlPivot08.html
Please be aware that the Difficulty level for this solution is Medium, suggest you to bookmark the solution from maintainability reasons, in case you choose to implement it.
The objective I am trying to achieve is to have 2 slicers in PowerPivot, ClientID and CSQName. When a ClientID is selected only the CSQnames that are related to that ClientID show up ,and vice versa
Relationship diagram link: https://goo.gl/photos/PnCZrnsXXTx3oFGh8
I am having a problem linking a many to many relationship in PowerPivot. A brief background on the application I am trying to build...
I am trying to combine a SQL database (IDM) and Informix SQL database (Cisco Call Data). The IDM database includes the Client Data and TBAS Open Case Data. Each Client has a specific ClientID. The Cisco database includes Call Detail Info and CSQNames(queue names). A many to many relationship exists, for example, a clientid can have multiple CSQname (clientid 3 has CSQ names of "A" and "B"). Also a csqname can have multiple clientids (csqname "Z" includes clientids "99", "98" and "97". Therefore I created an innerjoin table to create the many to many relationship called "Clients_CSQ".
I am trying to use this innerjoin table for both the "TBAS Open Cases" and "Call Detail". When I use this table for my filters, PowerPivot is stating that no relationships exist. Are there any solutions? If this does not make sense please let me know and I will try to specify. I have ready many posts but am unable to grasp how to make the DAX many to many relationship work with the calculate function. If someone can shed some light on the issue I am having it would be greatly appreciated. Thank you.
This really depends upon the data you are looking to report on.
When you add two slicers to a PowerPivot table, the available selections in each slicer will be affected by the selection in the other slicer IF and ONLY IF all of the fields in the Values section of the Pivot Table are reliant on the entries in both of the slicer fields.
In your case, it is possible to make this work (as an example) by creating 3 measures:
[Call Total]=SUM('TBAS Open Cases'[Case duration])
[Number of Calls]=COUNTA('Call Detail'[appname])
[Calls by Duration]=SUMX('Clients_CSQ',DIVIDE([Call Total],[Number of Calls]))
Place the last of these 3 measures in a pivot table with the slicers set to use 'Clients_IDM'[ic_client_id] and 'CSQ Name'[csqname] and "Hey Presto!"
The first two measures are straightforward enough. The third one is cycling through each entry in the only table that these two slicer fields have in common (Clients_CSQ) and performing a calculation using the data from your FACT tables. I have no idea if the [Calls by Duration] measure that I've come up with makes any sense with your data set, but hopefully the example will help you reach the solution you want. Again depending on what data you want to show it doesn't really matter if this measure returns junk, the important thing is that it's pulling your two data sets together.
Remember that as soon as you add any raw field from either of the fact tables to this 'unifying pivot table', the inter-relationship between the slicers will break. !!!BUT!!! there is nothing to stop you from linking the csqname slicer to another pivot on the same sheet which contains fields from your Call Detail table and likewise linking the ic_client_id slicer to a pivot that contains TBAS Open Cases data. In fact, the 'unifying pivot table' could be on a different sheet from your slicers, so you only see the two sets of data that you are interested in.
And ignore that warning about no relationships existing!
My Access programming is a little rusty, & I've never worked with Excel files all that much.
I have a requirement to bring data from Excel spreadsheets into Access 2007. These spreadsheets have a fixed (predictable) format, but it includes a "header area" where I need to read single data items from specific cells, followed by a mass of tabular data (~500 rows in the one sample I've seen so far). I will be processing all of this into a set of tables that are normalized quite differently from the flat layout of the spreadsheet.
I know how to open an ADO recordset on the tabular data, and it should work fairly well for my purposes. I also figure that I can reference the Excel object model and open the sheets through Automation to get the "header area" data items.
My question is this: since I have to (I think) use the Automation approach for the "header area", am I better off just leaving it open in this mode to move on to the tabular data (with cell/range navigation), or closing that mode & going over to ADO? I suspect it's the latter--and I'd be more comfortable with it--but I don't want to do the wrong thing just because it's more familiar.
Edit
It seems I wasn't clear that I need to build this capability into the "application", as something that a user can repeat down the line. I'm assured that I can trust the format of the spreadsheet (though I'll include error trapping for graceful failure if that turns out to be false). These spreadsheets are "official design documents" for hardware, and my app needs to handle bringing in new &/or updated ones to track the things that are described in the tabular data in ways that the flat Excel format diesn't allow for.
Of those two options, I would choose the second simply because I find it more convenient to work with an ADO recordset. It should be fairly simple if you can assign a named range to your spreadsheet's tabular data.
Edit: If your spreadsheet includes field names, the recordset approach would be less prone to break due to spreadsheet changes such as one or more new columns inserted before or between the existing columns or a re-ordering of the existing columns.
But actually, I think the TransferSpreadsheet Method might be more convenient. You can specify the spreadsheet range as a named range or by cell address as in this example from the linked page:
DoCmd.TransferSpreadsheet acImport, 3, _
"Employees","C:\Lotus\Newemps.wk3", True, "A1:G12"
Also, you can choose between importing the spreadsheet range directly into an Access table, or linking to the range as a "virtual" table ... whichever best meets your application's needs.
Edit2: Creating a link (acLink instead of acImport) with TransferSpreadsheet would allow you to execute SQL statements against the link table:
INSERT INTO DestinationTable (field1, field2, field3)
SELECT foo, bar, bat FROM LinkedTable;
If the header information is really complicated, this can simplify your coding work:
In the official design Excel file, create a hidden tab.
In that tab, make a 1-row table connecting to all the header elements you're interested in. (i.e. set row 1 column 1 to "Document#" and row 2 column 1 to Sheet1:A1)
Then you can re-use the same VBA procedure to import both your tabular data and your header data.
I would do it all via Automation. Why have two separate processes where one will do? After you've read the header information reading the tabular information will be quite easy.
I inherited an application back in mid-2000 that was built to import Excel spreadsheets that were basically reporting output from MYOB (an accounting program). What had been done was to simply create a template table that had all the columns necessary to accomodate the report, using text data type for all columns. Then the non-data rows were filtered out and processed into the eventual destination table.
It's not elegant, and doesn't require a lot of programming, though the implementation I inherited used a dedicated temp table for each report layout that was being imported. You could easily replace all of those with a single table with 100 text columns of 255 (or memo fields, for that matter, if that was a requirement), and just re-use it.
I'm not sure if I'd recommend it or not, but it really is quite easy without requiring much in the way of code.