I am trying to develop a manner in VBA to track changes in a document without having to hide the contents in an extra sheet within a workbook.
I understand that if you change the extension of an Excel file to ".zip", you can access the Excel document as components sorted into directories. Is there a way to save and write to a text file within one of these directories so that I can access it every time the document is opened, without having to have the user drag a log file along with the Excel document?
Some facts:
When Excel opens the file, the file is blocked by Excel. There is no possibility to write to that file within VBA
You can store additional data into that file externally or after the Excel workbook has been closed
You would need to have code externally from the workbook to accomplish writing to that file after it has been closed. You may want to use VSTO or an oldschool Excel Addin.
you have to ensure that Excel will not destroy your changes when restructuring or repairing the file.
In the first run, your idea sounds very natural, to not use sheets from a programmer's point of view. You only have full control on Excel files when
you use external libraries (e.g. Spreadsheet Gear) or
you remote control Excel via automation.
you use openxml SDK for Excel
you use VBA
You could insert additonal information and take care that this information is not skipped by Excel.
When you want to do the tracking this way, I would suggest you to use an Excel Addin. There is actually no need for installation when using this kind of Addin. Attach to open workbook and close workbook events and ensure that all changes are written to the Excel Workbook after it has been closed. Certainly you would have to attach to all kind of other events to track all changes to the workbook. You may need to have in mind that there can be more than one workbook opened at a time.
Actually there are alternatives.
write your logging code in VBA or whatever fits
abstract away how your persist the code (e.g. use a data provider)
think about these two alternatives to store logging data:
You can save logging data in cells of excel. When using a "newer" version of excel, you have a limit of 1 million rows. You may want to implement a rolling mechanism that ensures that you never go over the border of 1 million records. (you may be dont want to track a million changes)
You can use the document properties to store you information as xml.
Last but not least, the most obvious: Why not using Excel's functionality of tracking changes? Understand track changes in Excel 2013
Related
I have an Excel spreadsheet on a Sharepoint site that I would like to keep as read-only. However, my users will occasionally need to add small amounts of data, which I thought could be best stored in a small text file. I can read the text data into the Excel userform easily enough, and I can amend the text file with new data equally easy - but only if I have already checked the text file out. This doesn't work for other users of course. Is there some method of checking out a file - which isn't a workbook - out via Excel VBA, or will I have to switch to storing the updateable data in another workbook?
It is possible to use VBA to read textfiles. You can use this example for instance: https://www.excel-easy.com/vba/examples/read-data-from-text-file.html where you can read the data per line.
I have a heavily formulated workbook which will be used by staff members who will paste in potentially confidential client information. The workbook then comes up with graphics and data to summarize the imputed information
In an ideal world, the people using the program will be able to Save specific sheets as a PDF and would be able to close the program without saving changes to the worksheet but Excel always demands to save the template first, THEN will allow PDFs. This is obviously a problem as if a person uses it, paste's in a client's information and saves the result as a PDF then whoever next opens the Excel workbook will have that previous client's information showing.
SO. I either need a way to tell Excel to not require compulsory saving to allow PDF conversion or another option which will result in the same thing.
I should also note that the workbook has to allow users to paste in information so I don't imagine a Read Only will help :/
I have also attempted using a Macro-Enabled Template which still has the same problem
I imagine there's a ridiculously simple solution to this.
Thanks in advance
Does macro programming allow to read data from a table and hardcode it into another macro?
Situation is that I want to read all data from a worksheet with a macro. I then want to save that data without the help of an additional program to another macro so I can delete the table, restart my pc and still be able to retrieve all data from my macro.
You can "create a macro through a macro" (OPs words) through the VBIDE.
To so so, add a reference to Microsoft Visual Basic for Applications Extensibility. You can then write code to read and write to your VBA application. You will also need to set Trust access to the VBA project object model in the trust Center.
That said, there may be better ways to achieve what you want, eg
Hide the sheet using xlSheetVeryHidden so it's only accessable from VBA
Write the data to one or more hidden Names
If you are using .xlsm, these documents can also contain custom XML parts, which you can use to store arbitrary XML data in the documents. MSDN refrence: Custom Xml Part
I'm using Excel 2010 and adding a small VBA macro to a spreadsheet. (The purpose of the macro is to take the data on the active sheet and export it to a CSV file, but that's tangential to the question.) The macro determines the output path for the file using ThisWorkbook.Path. I also added a custom button to the Quick Access Toolbar to activate the macro.
After getting a working algorithm in place in my experimental spreadsheet (Test.xlsm, stored in one path), I made a copy of the spreadsheet in another path and renamed it to _Database.xlsm. Then I opened _Database.xlsm and ran the macro. To my surprise, the file was written to the original path, not the new one. And looking down at the Windows toolbar, I saw that Excel had opened the original file over in its original path as well.
After a lot of jiggering around with code tweaks, checking properties and such I finally found that I could prevent this by opening the copied spreadsheet, removing the Quick Access Toolbar button, re-adding it, and then saving the file. My questions are:
Why isn't the macro "independently portable" along with the spreadsheet? I.e. why does the copy maintain this kind of tie to the original sheet?
Is there a way I can create or modify the macro to make it portable in that sense?
If you want a toolbar/button to travel with a file (ie. not always link back to the original version) then you need to add it to the file itself, not to the QAT. The QAT only "knows" about the actual file you linked the button to.
It might be better to add the macro to your Personal Macro Workbook and then just have it operate on the ActiveWorkbook.
However, if you want to distribute it to other users, you can keep the macro in the "database" workbook and add a custom ribbon part. See: http://www.rondebruin.nl/win/s2/win001.htm
Currently we have a Excel VBA application, which consists of 25-30 Excel sheet (and all of those sheets all hidden and we do background processing on them and display it to VBA forms UI), and we have developed a UI using VB forms. But problem we are facing is whenever we click on Save button using this code:
ThisWorkbook.Save
But this saves entire workbook not an individual sheet, so even if we make changes in single sheet it saves entire workbook and this save processing makes very slow (since it needs to save all excel sheet containing lot of data unnecessary, even if there is no changes).
My question is is there any way we can save "only one sheet in a particular excel sheet" not an entire excel file?
Note: I am a Java developer and I worked on VBA before, But it was years back, and I have forgotten bit. Any guidance would be appreciated. Or any pointers on how to handle this situation would be appreciated. Please let me know if you need any more information, I can edit this question.
What I have tried already? I did a lot of research from yesterday, I searched in previous questions on SO, but didn't get any useful information. As per my research it says we cannot do this. Am I on right path?
The short answer is no. You cannot save a single worksheet at a time.
You may want to try to reduce the amount of data in the workbook. Try storing data in several workbooks and when it is needed, open that specific workbook, make the needed changes, and then close it.
If it is necessary to have access to all data at once then consider using access or some other database.
It is also possible that the sheets have "blank data". Cells that don't contain anything in them but excel thinks they do so when saving it tries to save way more than needed.
Assuming that it is the active worksheet that you want to save then you could do something like this:
ActiveSheet.Copy
ActiveWorkbook.Close True, "path"
This copies the active worksheet which creates a new workbook which will become the active workbook. Then just call the close method on that and give it a file name.
I think you should consider splitting your application into multiple workbooks:
The workbook that contains all the logic, user forms and programming code. This workbook handles all other workbooks as well as the displaying of it. Potentially, this could be even an "Application Specific Addin", that stays dormant but activates as soon as any of it's subsequent workbooks gets opened. For this architecture approach check out the section on "Application Specific Addins" in this link.
This workobook/add-in can also hide the other workbooks, so that the user will not notice it's multiple workbooks.
One or multiple data workbooks: Depending how interlinked the data is, you can separate this, e.g. in a "Sales data" workbook which contains the large database, as "Base data" workbook, that contains all the smaller data (e.g. products or stores tables).
This way, you can reduce the saving to the "relevant" sheets. However, of course this requires quite a bit of reprogramming - but it's worth the effort, as for instance it also allows to provide updates/bug fixes without having the transfer the data between versions, as you only need to distribute the the file with programming logic. :-)