I have written some pretty lengthy VBA code in excel for the comparison of 2 worksheets. My code does the following:
Lets you import 2 sheets for comparison
arranges the columns
removes departments which require different comparisons into a new worksheet
In sheet 1 checks if the id's appear more than once then checks, which row of data to use for comparison based on the latest update, and deletes the old rows
compares the sheets based on the header and then the cell contents as header names are different, for different values it then highlights them red
finally giving me a breakdown per column per department of differences and any id's that are missing
I have now found that my data set is becoming to big and looking to use MS Access, is it possible to copy my VBA code over to access? What do you guys suggest for this?
Any advice would be helpful.
From the nature of your question it sounds like you may not have used a database before. If you were using access, you would need to totally re-write the code using SQL statements. eg An Aggregating SQL SELECT statement to find the most recently updated update and ignore the rest.
You can use conditional formatting in an access form, but it's no better than using it in excel. How many rows does your data have? Will it fit in an excel sheet?
You might use access to pre-process the data to remove the unwanted rows that you use in excel. OR use power query or sql directly from excel to remove them.
You have a way to go.
Harvy
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 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?
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.
My current employer (to remain nameless) has a collection of incredibly sophisticated Microsoft Excel 2003 worksheets (developed by contractors, also to remain nameless).
The employer is replacing the Excel-based solution with a SalesForce-based solution (developed by other contractors, likewise to remain unnamed). The SalesForce solution is also very complex using dozens of related objects and "Dynamic SOQL" to contain the data and formulas which previously was contained in the Excel-based solution.
The employer's problem, which has become my problem, is that the data from the Excel spreadsheets needs to be meticulously and tediously recreated in .CSV files so it can be imported into SalesForce.
While I've recently learned I can use CTRL-` to review formulas in Excel, this doesn't solve the problem that variables in Excel have cryptic names like $O$15. If I'm lucky, when I investigate $O$15, I'll find some metadata explaining if n cells up and/or some other data m cells to the left, and/or (in rare instances) there may be a comment on the cell.
Patterns within the Excel spreadsheets are very limited, rarely lasting more than 6 concurrent rows or columns and no two sheets which need to be imported have much similarity.
Documentation of all systems are very limited.
Without my revealing any confidential data, does anyone have any good ideas how I might optimize my workflow?
It's not clear exactly what you need to do: here are 3 possible scenarios, requiring increasing knowledge of Excel.
1. If all you want is to convert the Excel spreadsheets into CSV format then just save the worksheets as CSVs.
2. If you just want the data and not the formulae then it would be simple (using VBA) to output anything that isn't a formula (the cell.Formula won't start with =).
3. If you need to create a linkage excel-->csv-->existing Salesforce objects/SOQL then you will need to understand both the Excel Spreadsheets and the Salesforce objects/SOQL that have been created. This will be difficult unless you have good knowledge and experience of Excel and also understand what the salesforce App requires.
Brian, if you're still working on this, here's one way to approach the problem. I use this kind of process often for updating data between SFDC and marketing automation apps.
1) Analyze the formulae that you're re-creating in Salesforce.com to determine what base data fields you need (stuff that doesn't have to be calculated from something else.
2) Find those columns/rows in your spreadsheets and use Paste Special -> Values in a new spreadsheet to create an upload file with values instead of formulae that you need for each data area (leads, prospects, accounts, etc.)
3) If you have to associate the info with leads or contacts or accounts and you have already uploaded or created those records in Salesforce.com, be sure to export them with their ID numbers. That makes it easy to use the vlookup formula in Excel to match up fields that you need to add and then re-upload the data into Salesforce.
Like data cleaning, this can be a tedious process. But if you take it step by step it shouldn't be too hard. Good luck.
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.