I have a large imported .csv as a (Query) table in an Excel workbook. I'd like for users of the workbook to be able to select a small subset of that data and update some values without having to play around with filters on the table.
To that end, I've set up a FILTER on a separate sheet, something like:
=FILTER(my_table[some_column], my_table[id_column]="some value")
That pulls in values from the relevant column and displays them.
My question: is there any way to allow users to edit the values retrieved with the FILTER, so that the changes are reflected in the original table? Attempting to edit such a value now just edits the underlying field, causing the FILTER to update and display #SPILL! (which makes sense, since there is not enough free space to render the result).
I've looked at options for FILTER, and thought about writing some custom VBA code to do what FILTER does "manually", and then watch the sheet for updates in that range - but that seems like a lot of coding to do something I would imagine is more commonly needed?
Am I going to have to code this up in VBA? Or is there some alternative approach to using the FILTER?
Related
It sounds very easy but I looked for this similar question, but looks like I didn't find suitable. Mostly are slightly different issues then mine..
I am receiving monthly one big Excel file, where I got different sheets, but only on one sheet I am having 3x different data ranges (not formatted tables). I am saying it again, ranges not tables, because some "smart" collogues decided just to overwrite file with new data but just to expand the range...so it stayed as range (it goes horizontal), and not table. For Power Query is needed table format I know..
So my issue is to somehow consolidate those ranges (3 of them) on that one sheet into one Query, but without disrupting the original Excel file, and of course to make it dynamic when I am getting new files.
I am comfortable with Power Query, but I didn't have similar things like this where you have more ranges that have to be cleaned, edited and appended into one query...Positive thing is, the column names are the same, just the content are different...
As you can see the data range is in so called "blocks" on data that are going horizontally...
This is basically something what I would like to have:
If question already exists please link!
Here is my test file to check it up:
https://docs.google.com/spreadsheets/d/1RDAoZqxKPk1NdhtcYec8nG_31PFwQ7Lj/edit?usp=sharing&ouid=101738555398870704584&rtpof=true&sd=true
I solved it by combining into 3x queries and then appended into one bigger table.
and, import From Folder is the best import, rather then direct from Excel Workbook, it gives me more space for adding the filter for instance "Date Created" so you can always have the newest on the top or whatever.
Thx anyways for some input of you guys.
I have an Excel 2010 data table which is driven by a query from MSSQL. The underlying query changes depending upon what options the user selects in the Excel workbook. I'm okay with changing the query and pulling the data.
After the data has been selected multiple users will be able to edit and append data to the Excel table and these changes will post back to the SQL database table. Due to the database table structure some of these cells within a given row are mandatory before any data can be inserted into MSSQL and/or potentially updated.
So what I'm trying to achieve is checks on whether certain columns in a row are blank after a cell is edited (I can do this via Worksheet Change) and also before they move off that row so I can bring up a message if all mandatory columns haven't been entered. I can't see any events that fire before Selection Change. My only thoughts on a workaround is to have a global variable row marker that is updated on Selection Change, i.e. it will store the previous row number. I can't use Excel's standard data validation functionality looking at blank cells because although this is fine for a currently correctly populated row that is being edited, inserting new rows or appending directly to the bottom of the table will constantly error as all those mandatory columns will, of course, be blank. Currently I am using conditional formatting to at least highlight columns/cells that require input although this doesn't force users to actually do it. Data cannot be stored within MSSQL until these columns contain data so if they don't fill them in and refresh the table for whatever reason, whatever they have entered will be lost. Obviously this is bad, m'kay. I am concerned about both the Worksheet Change and Selection Change events constantly firing and how that will affect workbook performance.
Any suggestions would be appreciated. Maybe I'm going about this all wrong so any ideas to make this more efficient would also be well received. The user base do not want to see UserForms or MS Access even though it would make this activity very easy. They are too used to the look and feel of Excel sheets.
your best way is to copy the table into 2d array or some other data structure in memory such as dictionary or collection. and than manage each change in memory. this one is very efficient but requires a lot of code. with excel the only problem you have is the key the rest is vlookup and true false questions. vlookup will find the original value and then you have current data + previous data + the logic... is the new data ok?
I have a database of data in excel that I want to copy and paste (link) to a new sheet where I can manipulate the data to a more readable form. However, the database does not have a set number of cells and updates regularly (the reason why it needs to be linked). The database changes size on a daily basis either shrinking or expanding. Is there a way to link the database even though it need to be a dynamic range?
I have a similar situation for one of my reports where I don't want to mess with the live data. All I do is create the link by going to the new sheet and typing something like =iferror(C:\USER\Database.xlsx\sheet1!A1," ") and fill across all the way and down all the way. The iferror checks for data and if there is no data inserts a space. That is how you can overcome the dynamic columns and with issues. The new spreadsheet will then be linked to the raw data set and you can manipulate it as needed.
I have got two adjacent tables. When I apply data filter on first table, it filters the whole row hiding rows from 2nd table as well. How do I restrict filter to only the first table range?
To answer your direct question How do I restrict filter to only the first table range? the answer is - you can't.
Reading the comments it seems what you need is to display the filtered table data next to a chart and another table. There is a little know tool in Excel that you can use to achieve this - the Camera Tool. With this you can create a dynamic image of a range and place it where you want. The image updates when a filter is applied to the source range, without affecting the rows on the Dashboard sheet.
Screenshots to demonstrate:
Setup with tables on seperate sheets, and camera images beside chart on dashboard sheet
With Filter applied to Table A
The Camera tool is not on the Ribbon (Excel 2010) or the standard toolbars (Excel 2003). You need to add it using Customisation. (Add to Qucik Access Toolbar in 2010 or Tools/Customisation Menu in 2003)
Unfortunately you won't be able to do that. When you filter, it filters the entire row (something to think about would be how the row number would display if that weren't the case). You will need to restructure your setup if you wish to prevent that (not sure of your particular use case, so sorry I can't give a more specific suggestion).
I had a similar issue, where i had a table I wanted to remain static - like a key, but wanted to filter the main table.
To get around this, I copied the static table, and pasted it as an image. This way, when you filter on the main table, the image remains where you have put it.
A simple workaround for this general issue that others may have mentioned (but I don't see here):
You can't filter just a range (e.g. a few columns in a spreadsheet), but you can sort just a range. And by sorting the range, then deleting some blocks of unwanted cells in the range, then sorting the range back to the original order, you can fake a filter.
A bit clunky, but easy for some jobs if you're careful.
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.