Is it possible to create a drop down list in excel that show data from a specific field from an access table? - excel

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!

Related

Pulling all info from open Access subform into excel

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.

Storing Collections through VBA in Access

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

Has anyone achieved to use ODBC connection from Excel file into Powerpivot?

I have installed Powerpivot for Excel 2010. I don't have Access 2010 so I thought could I arrange the data in the similar manner as I would for a database.
I'm wanting to query an excel file that has rows of self-generated data into Powerpivot in order to perform simple pivot table. In a sense attempt to get an overview of information about a data set.
At the moment, I'm unable to get set up correctly the ODBC I'm hoping I need to accept an Excel file and to get PowerPivot to accept a database from an Excel file.
Edit: I come to understand that I need to set up a table correctly in Excel so that the ODBC works correctly. Does the picture I provided be right manner to set up a table or any other manner?
Has anyone attempted to do this and if so what would the steps be?
Thanks,
Peter.
Peter, I am working on the basis that your data is in a recognizable table on a worksheet (and that you are not interested in using the standard Excel import method through 'From Other Sources')
If you create the connection to the Excel file in a very particular way it is possible to then query it as if it were a database.
Create a Connection to the spreadsheet in question in Excel through Data>Connections>Add.
In the PowerPivot window on the Design tab click on existing connections and find the connection you just created. Select the connection and Open.
You need to name the connection and then you will be offered the normal import options. Select the sheet you want to get the table from (its actually not important which one you choose at this point).
Once the table has been imported you can re-enter the setup through the 'table properties' on the design tab and you will now be able to 'Switch to' the query editor at which point you can not only write SQL to query your DB but reference any other .xlsx you like.
Jacob
the easiest way is to use a linked table from the excel sheet which has the data - is there any reason why you have not considered this as an option?

Import additional excel data into Access Table

We need to upload a small amount of additional records to a table from an Excel sheet. Is there a way to use the Access Import function to add the additional data to the table (truncate it). The table was created by uploading the same Excel sheet. But now, when records are added, we need to add them to the table. The tables are linked to SQL but I do not want to use an SSIS because there are only a few records and there must be a way to use Access functions. Suggestions please.
It may be easiest to link the excel sheet and run an append query to add data from Excel to existing table. Once linked, this can be done in the query design window.
You did not specify versions of Excel or Access.
I did this with a test 2003 Excel sheet with cells containing 1000+ characters. An import in Access 2003 detects the data type as a memo field, which is correct, when there are that many characters, so it should work for you. It may be your Excel data has other ingredients causing an import issue. How is the excel data derived?
Have you tried importing to Access? It should work fine. If your ultimate target is another database why use Access as an intermediary?
I agree a linked table seems like a really simple method to update a table if you are using Access, but that is your choice.

Creating a table in Excel

I was working on project for my company. The requirements are to create an excel report at the end.
The way I am currently coding/thinking.
Remote Server ---> Local Access table --> give user a UI to filter data however they want --> Export to excel.
However, one of my analysts asked me if we can stay away from access and use Excel only. So I was wondering, is there a way to create a "table" like access table in Excel? This way, when I import data from remote server, I can put it in a table (IN EXCEL), create a form for UI, and have everything contained in one file.
I can't paste the raw data into a sheet because of performance issues (however, I have not tried it. I just assume that it is a lot faster to query a 'real' table then to search through excel cells).
Can you think of a alternate solution?
One option is to use Microsoft Query to directly access the remote database. In this case, the users would need to use the UI of MS Query (which isn't the prettiest) for filtering, but it would get the job done without needing the intermediate database.
Here is a good reference from the Microsoft site.

Resources