Creating a 'Unique record' count in Access Web App
There is a situation where I am trying to find a count of how many unique values are associated with an item on a related table. How can I find this? Here's the scenario Business Opportunities 1 ACME Widgets Quotes Generated 1 Quote 1 for ACME Widgets by Paul 2 Quote 2 for ACME Widgets by Paul The desired output for Paul is Business Opportunities: 1 Quotes Generated: 2 However, when I run COUNT for opportunties, it shows 2, because two quotes are tied to the opportunity--disregarding that there is only 1 unique business opporutnity. How can I overcome this obstable and achieve the desired output in bold?
Navigation Pane Size Constraint Glitch
For some odd reason, when I drag to re-scale the Navigation Pane in Microsoft Access 2016, the pane becomes minuscule and I am unable to view anything. It makes sense to be able to hide the Navigation Pane by clicking the arrow to hide/show the pane (and this works perfectly fine prior to encountering this glitch), but the arrow to hide/show is no longer visible once the Navigation Pane is scaled down to this size. Usually, when you drag the slider all the way to the left, it automatically hides it, BUT if you drag it all the way to the left, but then move it slightly to the right, it will "glitch out" and you are left with a show-only version of the Navigation Pane that is unreadable, unscalable, and unhideable. The scaling arrows disappear/no longer exist, and the show/hide arrows are gone as well. It is still possible to open tables, queries, and other database essentials using the navigation pane, but it is impossible to read the names unless scrolling through (which is hard to do in itself). Please fix this bug, or add a way to reset the size and layout of the Navigation Pane. I've included the image at the top to show you how small the pane is, and the unavailability of the expected features. Thank you, -ZachI can sense a signal of life in Access Web Apps
Hi. From an AWB App, online, if you click the gear botton (top right) , there is a new command "Export to SharePoint Lists" this creates a subside with the name as in App name, creates tables with relashionships as in AWA App, and copies (i think copies) the data. this has been the first signal of life of AWA development team since years. i wish this is serious and wish see linking not copying to sharepoint lists, plus tens of other new fearures in AWA.
Has Microsoft forsaken Access? (by an "amatuer" Access developer)
It seems to me that, over the past eight years or so, Microsoft has increasingly underestimated and misinterpreted the benefit of Access. For example, I can't understand why MS would develop an application like Forms without creating the functionality that would allow for the easy export of data collected in a form to an Access database application. For me, the Forms app is useless if I cannot easily figure out how to dump the data I collect using Forms into my Access database application. For the record, I am not an Access developer. I am merely a lawyer who lacks proficiency in any programming language but understands the concept and benefits of relational databases. My understanding was forced to evolve over the past twenty years as a result of my numerous needs to collect, mine, and utilize clean data in the most efficient manner available that also integrated into daily operations and, thus, minimized the creation of additional data-entry tasks that would inevitably be ignored whenever things got busy. In most cases, the "amateur" applications I created to collect and mine critical data -- originally intended as an interim solution -- became the "permanent" solution after I left the particular project. Not surprisingly, this happened because other colleagues were not able to sufficiently communicate their detailed needs in a format that professional application developers could understand. Over twenty years have passed since I began working with Access, and yet, based on my observations, this vast communication gap between the end user and the application developer continues to be a significant barrier to progress. This is remarkable in light of the fact that the costs of the hardware/software required to realize greater efficiency have reduced dramatically over the same period. I have often explored other options for creating and maintaining a relational database application tailored to my specific needs, but Access remains the easiest and most cost-effective option -- especially when my needs demand more complex functionality. My experiments with pre-packaged applications have always led to the same conclusion: Access enables me to design an app in far less time that does more at a lower cost and that can be more easily adopted by other end users in my office. I have often explained it to both developers and end users in this way: Access enables me to compose complex musical pieces to be performed by a small orchestra without first having to learn to read music. Unfortunately, it appears to me that MS fails to appreciate the significant benefit this attribute could provide to countless new users. Another under-valued benefit that only Access can provide to smaller organizations: when end users learn to create simpler database applications in Access, their ability to communicate complex functionality needs to professional application development teams simultaneously and exponentially improves. This, in turn, reduces unexpected costs, frustrations, and disappointed expectations that too often result from ineffective communication between the end users and the development team: an all-too-frequent experience that leads to long-term negative consequences of increased costs associated with end-user training and adoption; increased resistance to change and innovation; reluctance among leaders of smaller organizations to pursue further development projects. For the foregoing reasons, I urge MS to re-evaluate the significant needs that could be fulfilled by promoting Access as a cost-effective tool for small businesses, organizations, and innovative grant-funded projects all of which typically lack both the financial resources to hire a professional developer and the time/capability required to communicate needs during the development process. I also hope that MS will pursue functionality that allows amateur developers/end users like me to easily integrate data collection from newer applications like Forms with the storage and querying functionality provided by an Access database application. To promote Access for use in smaller organizations, MS should, in my opinion, design training materials and experiences for beginners that present design and functionality concepts in a manner that is tailored to the varying perspectives of different categories of end users. For example, paralegals and attorneys working in a small law office would immediately grasp the benefit of a system that eliminates the need to repeatedly type the same information into multiple documents throughout their workday. As such, I suspect a training class that took these users through the process of creating an Access database app and integrating the app with Word to allow for the export/merging of field data to multiple legal document templates would both be well received and ignite a desire to pursue other projects.
