We are using a access front end that is being developed externally. It displays a form that contains numerous points of data and a few subforms.
I am trying to code a excel sheet that would pull data from various places in the currently open form.
I have gotten as far as to be able to access all the points of data in the main form and the first line in the subforms using the following code (In this example, the "pnum", is the left most field displayed in the subform):
Set objacc = GetObject("xxxxx\Database.accdb").Application
Debug.Print objacc.Forms("mainform").Controls("main subform").Controls("Pnumber")
This works and gets me the value of the very first element named "Pnumber" in the main subform.
However, the way the subform is formulated, it can have anywhere between 1 and 30+ "Pnumber" fields.
I need a way to pull everything that the currently visible (filtered down) subform contains regardless of how many lines there are.
Thanks!
If I were the developer of that Access application, and you asked me for this feature, I would code an API for you to automate getting the right data.
One approach I can think of in this particular case would be to populate some temporary tables, on request from Excel VBA, and have Excel use the Access database file as an external source of data. Or Access could be coded to push the right data into the open Excel worksheet.
The way you would get access to the data in its current state in the form (filtered, sorted, etc.) would probably be best through the RecordsetClone property of that (sub)form. At least that's what I imagine I would use to implement that feature.
Related
Helo I'm trying to create a calculation sheet in excel that I wanted to have a drop down cell where user could select one product name from a existing access database. I also wanted to retrieve in another excel cell the price of selected product that is also in the access database (like a procv command, but retrieving data from access). Does anybody know how to do it? I wanted to avoid to replicate source access table in excel. I wanted something more direct. I konw some basic VBA if needed.
Unfortunately, directly linking a control in Excel to an Access database isn't going to be possible. These products just weren't intended to work this way. Typically one would create a form in Access and on that form have the combo box reference the table there. Other user input could be added and calculations done etc, and then the final calculated values could be exported to Excel for further manipulation if needed/desired (that can easily be done in VBA).
That said, an indirect link could be done using VBA. You would add the "Microsoft Access 16.0 Object Library" reference library, create a connection, db and recordset objects. There are tons of resources via Google (or here) on how to do this.
With those in place you can conduct SQL queries against the database to pull the data over and update the combobox by clearing it's contents then re-adding from the query. You can put the code to update the combobox in any trigger you need.
Otherwise, the only other way would be to do what you said you didn't want to, replicate the database table in Excel.
I hope this points you in the right direction! Good luck!
I have no previous experience in Access, VBA coding or in Excel macros prior to teaching myself the past month via these forums. Thank you forums and contributors. I have enjoyed my Access learnings so far, the challenge that it has provided and appreciate any help that I can get. As such, the code and methods that I have used to this point may well be convoluted and confusing. I will do my best to provide relevant details and accurate terminology.
I work in a lab and I am creating an Access Form for semi-automated reporting. Samples are received from clients and are logged into the Excel Table R&D Log. The worksheet is InProcess. Samples are sorted based on the site in which they originate and given a one or two letter site code (G, D, WH, etc.) and an ID "yy-000" in separate Excel columns (i.e. D 18-096). Samples may be submitted for multiple analyses (Metals, Water, Soil, etc.) and may even have multiple rows of reporting if multiple analytes are identified in the sample. There are several other columns, such as receipt date, reporting date, units, etc. Once samples are reported, I manually copy and paste them into the Archived worksheet, and delete the record and blank row from the InProcess worksheet. Since one sample may have multiple analyses and even more potential results, each record would be reported on a new Excel row (with the same D 18-096 ID number). Thus, there is not a single unique identifier or primary key for each sample in the current format. R&D Log is updated manually by lab technicians and the worksheet InProcess is a linked table in an Access Database.
The Access Database is using two combo boxes on a Form frmInProcess to filter a Query qryInProcess of the linked table. The combo boxes are filtering the report destination (one client may receive multiple site codes) and the analysis (reports are separated based on type of analysis). The Query is also filtering out blank results and blank dates, so only completed samples will appear on the filtered Form. I have generated VBA code to this point that will export the Form to a .pdf, save the file with unique filename, and open outlook to mail out the report. I have also managed to export the filtered Form frmInProcess to an Excel file Access Test (not the linked file).
What I would like to do now is to automate the transfer of completed test results from the Excel worksheet R&D Log: InProcess to R&D Log: Archived and delete the record from the InProcess worksheet. I am not sure if I can export the filtered Form into a linked Excel table, or if I must use a separate Excel file (or if it even matters for simplicity of code?). I would now like to read the exported filtered Form in Excel Access Test, lookup matching rows in R&D Log based on several criteria (site, ID, Analysis, Analyte, Report Date) and automate the transfer of records between R&D Log worksheets. End result being that Access generates reports for completed tests, and the records are removed from InProcess testing and transferred to Archived testing in Excel. I am guessing that I may need to close the Access application and perform this in Excel. Hope this is easy enough to follow.
Thank you.
In my experience, importing an Excel document into a temporary NEW (or totally empty) Access table is usually the easiest way to go. Then you do not have to worry about cell references like you do in Excel VBA. Even if the Excel document has old data in it with just a few new changes each time, importing it into a temporary Access table could be the simplest way to go, because then you can compare the data in this table with the data in another, permanent Access table and update the latter based on the former.
As far as the original Excel file, if you need to delete rows there, it might be quicker to export a new Excel file with just the data the old one is supposed to end up with, and then use VBA to delete (or - safer! - rename) the old file.
So the development process goes something like this:
Save import steps by first importing an Excel file via Access' ribbon options "External Data" (tab) ->"Excel" and when you finish, be sure to check the "Save import steps" box and note the name you give the "saved import" because you will need that in your VBA code.
In Access, write a function for deleting the table. The VBA code is:
Const cTable = "MyExcelTempTable"
If TableExists(cTable) Then
DoCmd.DeleteObject acTable, cTable
End If
Now you can test your delete function on the data you imported.
Write VBA code to import the same spreadsheet to create the same table:
Const cSavedImport = "Import-MyExcelTempTable"
' Import the Excel file
DoCmd.RunSavedImportExport cSavedImport
Write more VBA function(s) to check the imported table for bad data and then to copy it into the permanent table. You might be updating existing records or adding new ones. Either way, you could use Access queries or SQL to do this and run them from VBA.
Write a VBA function to rename the old Excel file. (You could use an InputBox if the Excel file name is different each time. I do this for importing Excel files, and I set a default value so I do not have to type as much.)
Write a VBA function to export the new version of the Excel file.
Make yourself a button on a form that, when clicked, runs a VBA function. Inside that function, run Steps 2 through 6, above.
I am not sure my answer exactly matches what you are trying to do, but hopefully you get enough of a picture of the workflow to figure out the details of what you need.
Hello and thanks for any help. I'm a noob with Access but my company has asked a question about possibly importing some information for certain records in Access. Basically, I work for an insurance company and they have a claims system which was built in Access about a decade ago by someone who has left the company recently. The system works and is fine for current needs. However, we were recently asked to amend a field for certain records (claims). Because there are about 200-300 records, we are looking at a possible import solution.
The problem is, I have never done this before and am worried that it might affect other records or other fields in the records. The only thing that needs to change is one field and the rest must remain unchanged.
I know the Access table name & record numbers (RecordNo - textbox in Access) and the name of the field I want to change (Reference - textbox in Access) but am unsure how this can be imported, how the excel file needs to be prepared and how to make sure no new records are added but instead existing records are amended.
For instance, can I just have 2 columns, one called "RecordNo" and the other "Reference"? Or do I need to add blank columns to account for the extra columns in the Access table? Do I need to create a named range or an excel table or simply put the columns in Excel? Is there any specific formatting that I should be using (Text or General or something else - the Reference will be a text value as it has both numbers and letters)? When importing in Access using the import wizard, do I need to choose "Append a copy of the records to the table"? How will it know which record to amend as the Access table will contain thousands of records that I don't want changed in any way?
I also have access to the "Navigation Pane" in Access where I can find tables and queries etc and not sure if the records in question can be bulk amended on the table instead?
To make matters more complicated, the Access database is on the server and needs to be accessed by multiple users at the same time so I would ideally like to test this out on a separate copy. But copying it to my own computer does not sever the connection with the copy on the server and any changes are reflected in the original copy immediately.
I tried looking online but I can't seem to find anything that will quash my worries. I can find a few articles talking about importing issues, though not what I would be interested in, but they are all for previous versions of Access and really I can barely understand the current version. We are using Excel and Access 2013.
If possible, I would rather not use VBA as the current database has a lot of it anyway and its's difficult to manage and navigate. I also have no idea about Access VBA, just excel.
Thank you
To make matters more complicated, the Access database is on the server
and needs to be accessed by multiple users at the same time so I would
ideally like to test this out on a separate copy. But copying it to my
own computer does not sever the connection with the copy on the server
and any changes are reflected in the original copy immediately
That is because you are only copying the front end. There is somewhere a separate access file that is the back end. Or it could be a different database system like MS SQL Server or MySQL. So your first task it to find where the actual data is.
Beyond that, under no circumstances import an excel file directly into an existing table. Create an excel file with the necessary fields (record identifier and new value) and import it as a new table, then create an update query to effect the changes you need.
In my Access 2013 Desktop database, I want to validate an Excel form through VBA before importing its rows to a table.
The problem is that the imported Excel table may contain in the same column values that are numeric, string, null, etc. depending on the row due to mistakes from the user, so these values have to be initially of VBA type Variant before validation.
If the row is invalid (e.g. one value is not of numeric type while it should be, one mandatory field is null, etc.), I want to be able to store its values and let the user correct it later on. I am therefore looking for a way to build a table where I could store these rows, but where the fields are kept intact, so with the possible mixed data types.
This seems not to be possible, as Access tables need apparently to have fields of a defined type, so nothing equivalent to Variant.
How could I achieve this? What would be the simplest and most efficient way to store rows of Variant values while keeping the structure of the columns? The only way I could think of so far is to concatenate these values for each row in a string using some defined separator, and store this in a String column in an Access table, but maybe there is an easier way to do?
Thanks a lot for your help.
EDIT: Reading your answers I realized that I forgot to specify that the people filling and sending the Excel forms (who typically do not have Access on their computers) are not the same users than the ones who have the Access database and need to import the data. In this configuration it is impossible to use directly Access forms to input data, which would of course simplify tremendously the task. While we try to enforce rules for people who fill the Excel form at the first place there will be mistakes and the Access application needs to cope with them. And the importing process for the users manipulating Access should be as simple as possible (these users are not experts in IT).
I though about your problem for a while and made a few notes as I thought below.
I would strongly advise that unless the excel workbook is providing other functionality that you do not use excel, but create an simple Access database with a form they can use to interact with "their" data. They do not necessarily need an Access license to do this. Access 2013 even has new web features that can be used if you have sharepoint to collect data via a Access created web frontend.
If you are to collect data in Excel, then you must use excel validation and VBA code to validate the data as much as possible before transferring to access.
There are complexities that may or may not be an issue for you, things like:
Can users edit/created/delete the same rows concurrently - what happens if they do! You may need to "lock" rows when they are downloaded from Access. But what happens if tow users add the same record, or ones deletes a row before another user commits it back again.
Can a user open multiple excel files and edit the data they store without committing the data to Access?
Can multiple users login to the same Workbook with uncommitted changes and edit the data.
Using access will simplify your code as it will be able to prevent erroneous data being entered and remove the need to deal with the above issues and others
In summary you are using excel as a front end "form" to data stored in Access.
Each excel file can have data that has yet to be up
I would suggest that the primary key of a row is the "path and name" of the excel file that was used to create it & a unique numeric identifier. The unique identifier is a counter that is maintained for each excel file. The "path and filename" could be replaced by a unique identifier created for each file.
Many users enter data using multiple instances of Excel into a form which results in one or more rows being updated/inserted/deleted in an Excel table stored in each spreadsheet.
I would expect that whenever Excel is opened the user enters a username and excel will grab "their data" from Access. Alternatively a workbook might be set up for each department or "case type" and only interact with data that matches this "custom criteria set up in the workbook". Excel would not necessarily need to store data itself longterm. The workbook might always save data back to the database when it is saved.
You say Excel VBA performs limited validation on the data (but no complete validation). It should be used as much as possible and arguably should be able to do exactly the same validation that access can do. At the very least it should enforce datatypes etc (eg using the standard data validation rules on the excel data menu) or perhaps use VBA/controls to get any access data it needs to validate the data entered.
After updating the data the user can "commit" (ie save) the data to the access database. Before closing the workbook you might want to commit the data.
(An issue is whether a user might open many workbooks perhaps on many machines without committing the data.)
An Access "staging" table can be created with all columns having the datatype "shorttext" and not-required.
The process that loads data from an excel table into Access, will uploaded all excel rows into this staging table. It will then validate each row in the staging table and process all valid data into the main table(s) that have data types, relationships constraints etc.. Any valid rows in the staging table are flagged as "VALIDATED & TRANSFERRED", Invalid rows are flagged as INVALID. The "VALIDATED AND TRANSFERRED ROWS" are subsequently ignored, but kept so you can check what processing has happened, perhaps only whilst testing.
The data in excel is then updated with the Valid/Invalid status from Access and suitable messages given to the excel user. The user may correct and then re-commit the data.
Each excel file has a status of "changed/Unchanged" to indicate whether a user has changed data in the file.
When a user opens an excel workbook and status is unchanged it will refresh it's data. If it's changed a refresh probably can't be done.
In order for the data in Access to be updated/deleted/inserted with the changes made in Excel, there will need to be a unique identifier for each row that cannot be changed by the users in excel. This is likely to be the Path&Filename or the UserName logged into Excel and a numeric counter (which is maintained for each file or user). (This assumes that the user will have to commit changes in one excel file before they work on another.)
Anyway, without knowing more it's difficult to fully design what you will need, but I hope these thoughts help you
Harvey
We have report and users want to upload filters to prompts on the reports from excel or csv files. They cannot enter one by one because they sometimes have hundreds of values (customer numbers) to filter. Is there a way to do that? If it is then how is it possible?
Thanks in Advance.
Niki
I'm assuming you're using either Web Intelligence or a different document format that is supported by the OpenDocument feature.
One possibility is to use an Excel file with a column for each prompt value. Use this Excel file as a source for a new Web Intelligence document. Within that document, construct OpenDocument URLs that contains the prompt values you want to pass.
Make sure that you read the OpenDocument manual carefully, as the syntax for passing prompt values differs depending on how the prompt is configured (single value vs. multiple values, etc).
The idea behind this is that you have an easy to maintain Excel file to input/modify the prompt values, and that end-users can open the intermediate Web Intelligence document, refresh it (or use refresh on open) and then click one of the generated links to automatically open the correct document and have all the prompt values filled in.
Example
Consider the screenshot below. It's an Excel file that contains information regarding two documents (Dummy Report and Other Report) as well as their internal ID (CUID) and the prompt values to refresh them with.
This is sufficient information to generate an OpenDocument URL to open these documents for us and automatically enter the prompt values.
The resulting URLs would look like this:
http://<servername>:<port>/BOE/OpenDocument/opendoc/openDocument.jsp?iDocID=Aa6GrrM79cRAmaOSMGoadKI&sIDType=CUID&lsSYear=2015&lsSMonth=2
http://<servername>:<port>/BOE/OpenDocument/opendoc/openDocument.jsp?iDocID=Aa6GrrM79cRAmaOSMGoadKI&sIDType=CUID&lsSYear=2015&lsSMonth=2&lsSCity=Berlin
Some remarks here:
If your documents have different prompts (e.g. City is a prompt in the second document but not in the first), or some of the prompts are optional, you'll have to check for which columns (prompts) a value has been provided in the Excel sheet and discard the empty ones (should be easy enough).
Unless Single Sign-On (SSO) has been configured in your BusinessObjects environment, you'll still have to log on.
Due to this approach, you can make prompt values dynamic (e.g. use the current year) by using Excel formulas.
The example above is a very simple one. You could have multiple lines referring to the same document but with different prompt values.
Taking it one step further
If you use this Excel sheet as a data source for a Web Intelligence document, you can create a Webi document that contains the OpenDocument links. The added bonus is that you won't have to log on anymore after clicking one of the links, as you're already working in an authenticated session.
Important
Make sure you read the OpenDocument manual carefully so you understand what it is and how it can be used (and more importantly, what you can't do with it). You can find the manual on help.sap.com. Just make sure the version described in the manual corresponds with the version of BusinessObjects deployed in your environment.
Not currently possible. What we did for this requirement was to create a new dedicated table in our database to hold customer-generated prompt values. We then created a simple web page to allow users to upload lists of values. Finally, we created universe objects that associate the customers' LOV table with existing universe objects as filters.