I have a rather unique problem that sits between the solution sets I've been able to find. I have a database containing tables that need iterative select queries with updating input parameters. As an example, I have an equipment table that contains a pairing of a technology with a sister tech, and the mechanisms through which they communicate:
Table Fields:
TechID1
TechID1Port
TechID2
TechID2Port
Example: Radio communicates (through its low/high band antenna) with Basestation (through its antenna port)
I have working SQL code that runs when users select TechID1 from a Combobox and the Combobox value filters the WHERE statement. However, I need to add levels of interaction based on a just added Combobox (values:1-n). The end goal is to iterate the query as done here, but without VBA, as this solution needs to be replicated for many Access tables and seamlessly transferred to Oracle/SQL Server in the medium-term.
Example of desired nth level results based on Radio selection: List of all techs that directly interact with Radio (plus associated info), with an appended list of all techs that interact with Basestation and other 1st level results (no duplicates or trackbacks to Radio), etc to the nth level.
For the above to work without VBA, I realize there is likely a series of similar/identical queries that need to run, with the ability to analyze only the row entries for the interaction level below the current run. One simple potential solution I've looked at is nested subforms that allow users to expand higher interactions as they wish, but I can't find a way to subform and filter a table onto itself.
Big thanks in advance!
J
Have you tried to use temporary tables.
You would be able to filter with different (sub)query's
Related
I have an Azure SQL database, and my records inside table Spiderfood_RITMData in that database includes 13 different fields. Lots of stuff. I have confirmed in SQL-SMS that the records have data in each field.
There are way more items in the database than PowerApps can see using LOOKUP (1600-9000 records or more). However, I know FOR A FACT that there is only ONE record that has any given value in the NUMBER column. It's not a primary key, but it is unique in the table.
In PowerApps, I am trying to pull that field so that I can eventually parse out the individual items.
So, the commands I'm trying are:
ClearCollect(MLE_test1, Filter('Spiderfood_RITMData', "RITM2170467" in Number));
ClearCollect(MLE_test2, Search('Spiderfood_RITMData',"RITM2170467", "Number"));
However, the Collection results for MLE_test1 and MLE_test2 both are empty EXCEPT for the value of NUMBER. Say what?!
I'm trying to use the examples posted on https://learn.microsoft.com/en-us/powerapps/maker/canvas-apps/functions/function-filter-lookup but I am honestly getting baffled by this.
How should I be formatting this call such that I can pull the whole record?
Big picture explanation: I need to do a lot of data LOOKUPS into my table Spiderfood_RITMData table, but it has way more than 2000 rows, and PowerApps will not perform the Lookup correctly. So my presumably smart idea is to create a MUCH SMALLER "version" of Spiderfood_RITMData as a local collection, using a more delegateable function (such as FILTER or IN). If I filter by all records containing the values of NUMBER, then I go from, say a 10,000-record SQL table to a 10-record Collection. And I can do LOOKUPS against that collection for the rest of the function (uh, I think -- I'm still trying to experiment accordingly). Please let me know if this is crazy or not.
LookUp is just used to get one record, instead try this:
ClearCollect(MLE_test1, Filter('Spiderfood_RITMData', "RITM2170467" = Number));
This gets a collection with all the items where Number is = to "RITM2170467"
Collections are limited to only 2000 records in each collections.
I had same issue. Go to App settings. Under Upcoming Features make sure Explicit column selection is turned off. Hope this does it for you.
I am helping a colleague with a system he has been tasked with where we have a form that has multiple sections and many of those sections can have sub-sections and those 2nd level sub-sections can have (third level) sub-sections themselves.
So, we have multiple User Defined Table Types, one that has the top level table structure, then inside of the first section there is a UDTT (let's call it subject as it is both sides of the problem in question), then inside of each 'side' we have another UDTT, perhaps their contact information, multiple phone numbers with a type column for each.
And there are n top level sections where up to n of them can have second or even third level UDTTs associated with them.
Now, I like using UDTTs to import large datasets from some kind of external source (usually a webpage where somebody has uploaded a large Excel or CSV file), but I have never had the circumstance where I have needed to pass multilevel UDTTs to a single stored procedure and I am not even sure how that would work, but in my quest for efficiency I am trying to find a way to do this without a while or for loop.
So... any suggestions?
You can't submit UDTT in a nested structure because a UDTT cannot contain a UDTT as a column within it.
However you can solve the problem by flattening the data and using a key field to links the children to the parent. For this you would need 1 parameter per different UDTT structure you are using and then rows within those parameters are linked using the key field to build your hierarchy.
You can then recover you original structure within the stored procedure depending on what actions you wish to take.
tldr: Can not update records from query because of aggregate functions. What workarounds do you suggest?
I have a table containing decision criteria to which a user can assign a relative weight. I calculate the absolute weight in an SQL query using an aggregate function (as described here Divide the value of each row by the SUM of this column).
qryDecisionCriteria
name relative_weight absolute_weight (calculated)
price 2 50 %
quality 1 25 %
experience 1 25 %
I would like to present the query result in a form, where the user can update the relative weights, and then sees the absolute_weights.
However, the query results are not updatable, because the query involves an aggregate function.
What alternative methods or workarounds could I use, so that a user can edit relative_weights and view absolute_weights as a kind of visual feedback?
I read about temporary tables here http://www.fmsinc.com/MicrosoftAccess/query/non-updateable/index.html but I'm not sure, how to implement this.
Maybe I could also create an additional "edit form" based on a simple query, that is automatically invoked when the user selects a record in qryDecisionCriteria data?
Or maybe just display data from two queries (one updatable, one with the calculated field) next to each other in the form?
Which options would you recommend and why?
Make the Record Source for the form the updatable base query. In the text box which shows the calculated absolute weight set the control source to
=DSum("relative_weight","<base table name>")/Forms!<Form Name>!relative_weight
You'll need to be sure that you do two things with this
When you drag fields onto a form in Access it makes the name of the control the same as the control source column. this is really annoying and can cause a lot of headaches. Rename your control to something like txtColumnName. That way Forms!<Form Name>!relative_weight is guaranteed to reference the field and not the textbox.
in the AfterChange event for the relative_weight textbox you should add an event handler in which the following code is run
txtabsolute_weight.Requery
This will make sure the formula is recalculated whenever someone changes a weight. Otherwise they need to hit F5.
I have a table in Access linked to a SharePoint list. The table is comprised of about 15 fields whose contents are originally pulled from another data source (in Excel format). There are an additional 10 or so fields after the original 15 that make up a questionnaire (added via SharePoint) that contain answers to questions about the first 15 fields.
The data in the first 15 fields needs to be updated periodically when new data from my external source is available to download. A lot of the information will remain the same, however some of the fields within each of the rows will change and need to be updated. It is also important that the 10 fields that contain the questionnaire are not modified at all during this process.
Is there a way for me to easily update the cells that have changed using an Update query or something similar? The data does have a unique identifier column (ID NUMBER) that is present on the current SharePoint list and the external data source.
I was thinking from a logical standpoint to put the new external data into a table, find the ID Number in the SP list and new external data, compare the values in the rest of the row on the SP list to the row of the external data, and if a value is different update the cell with the value from the external data. Not sure how to accomplish this using Access queries though.
I really appreciate any help at all! If you need more information, please let me know. If you think there's a more logical way to do this, please let me know your feedback!!
Here's how to get started:
http://workerthread.wordpress.com/2009/02/03/using-access-2007-to-update-sharepoint-lists/
After you get the connection set up, it's just a matter of writing the queries correctly. If you need to run multiple queries periodically, you can setup a form with buttons, and attach some VBA code to the buttons that runs the queries.
MS Access - execute a saved query by name in VBA
Like a lot of developers who are comfortable with SQL syntax I get frustrated when working with Access's query editor. I'm talking about the raw SQL Syntax view, obviously.
One of its many annoying properties is that upon saving it will discard my layout / formatting. When reopening the query all I see is a bunch of unformatted SQL.
However, if my syntax is long and/or complex enough I've noticed that Access will retain my formatting and layout and, oh joy, the query remains clear and readable. I'm looking at an example right now with a page of SQL containing couple of UNIONs all nicely laid out from a few days ago.
At what point does Access flip over to allowing the user to retain his own formatting? Is it length? Complexity? And is there maybe even a trivial structural edit (if trivial structural isn't an oxymoron) I can make to all my queries which will force Access to leave my layout in place?
There are certain things that Access' query editor is not able to display in design mode.
Queries with UNION are the only thing that come to my mind right now, but there are probably more.
In my experience, Access always changes the layout as long as it's able to display the query in design mode.
As soon as you put something in the query that Access can not display in design mode (like UNION), Access leaves your layout and formatting as it is.
I couldn't figure out why Access kept changing my format in a union query (but not for every query or table included).
I simply created another SELECT query based upon the Union query and corrected everything in design view. It's a lot easier.
When I created the SELET query based upon the UNION query, I included tables or queries that I used as lookup tables and had formatted a field to select the second column from a record in a lookup field that the ubion query had anoyingly converted back to the first field in the selected record (usually the ID No of the record).
For example, I might lookup the account name in a record in the cash disbursements table that should display "Office Supplies Exp" but the Union Query converts at least one of the queries or tables I have combined in the union query to the Account Number, the first record in the lookup table, which was originally hidden in the lookup field.
Just to add to Christian's answer, I've done some more testing and find that UNION and DDL queries are left alone by Access.
If we add Pass through queries to that list, then that would match the queries deemed SQL Specific on the menu:
So, those would seem to be the three special cases.
Before saving just type the word union before the ;.
After opening Access next time, remove the word union and start working. When you want to save, first type union again.