Feedback by UserVoice

B. Clothier

My feedback

  1. 159 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    14 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    When you consider that there are Access applications that has worked in previous versions, and the only difference is that they upgraded to a new version of Access, it becomes a HUGE disincentive for them to consider upgrading the application, which is also bad in terms of supporting because that broadens the scope of support. If you want them to upgrade, you need to be able to provide same experience they had with the previous versions -- not running out of memory just because they only have 20 forms open. Access has long ago published a specification of hard limits and that has not been changed since. Enabling the LAA would be a simple way to enable those complex application continue to run well on newer versions of Access.

  2. 34 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Access (Desktop Application) » Other  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    Nothing's truly free, but when you consider that the methods was introduced in order to support the original SCC integration, it's probably good to ensure that they are aware that removing the methods would do more harm more than good.

    B. Clothier shared this idea  · 
  3. 24 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Access (Desktop Application) » Forms  ·  Flag idea as inappropriate…  ·  Admin →
    B. Clothier shared this idea  · 
  4. 121 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Access (Desktop Application) » Local Data  ·  Flag idea as inappropriate…  ·  Admin →
    B. Clothier supported this idea  · 
  5. 294 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    29 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    B. Clothier supported this idea  · 
  6. 219 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    11 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    Here's a bunch of compelling reasons why Access should update its ODBC support:

    https://github.com/Microsoft/ODBC-Specification

    Imagine Access being the first kid on block to support web authorization. See it handle JSON or CSV more effectively than it can. A bunch more....

    An error occurred while saving the comment
    B. Clothier commented  · 

    OMG, I didn't even add true in-memory/disconnected recordsets to the original list! Yes, that's definitely something else. With DAO, you sort of work around with temporary tables but that's LOT of coding, not to mention additional coding just to sync back the changes. That might be implied with #1 (async operations) but disconnected recordsets --- especially when it works with bound forms/reports --- would help enable many more scenarios without bloating the front-end.

    Yep, DAO has a lot to catch up. Time to 1+ up!

    An error occurred while saving the comment
    B. Clothier commented  · 

    Just to offer few user stories for why this feature would be helpful:

    Imagine wanting to be able to add a new invoice, which normally means entering a record in the invoice header, then the line items as several records on the subform. Now imagine wanting to cancel the invoice.

    With the bound forms, it is next to impossible to do this transactionally where a cancel should just mean discarding the data for both header & details and rollbacking the transaction. One must resort to additional coding (wait, we use Access to write LESS, not more code) just so that we can ensure that incomplete invoice don't end up saved in the database. Ability to control the transaction across bound forms would help enormously in that respect.

    Another example is when there's a slow connection, as soon as an user commits update, the whole form freezes, forcing the user to wait until the update has been committed. Modern applications, (including Access when connecting to SharePoint) allow background update with signal notification to indicate that a update is pending and should signal an error if it fails for some reasons. The more advanced users can use events to trap and deal with it more gracefully (e.g. retrying for transient network fails or to ensure user do not leave the form until all has succeeded). ADO allowed you to subscribe to events directly to the connection or recordset objects; DAO has NO events at all.

    Imagine being able to define a recordset and re-use it easily for multiple controls on different forms. Suppose we have a zip lookup functionality. Using a direct query on a combobox can be very expensive since Access query for EACH control separately. Currently this is only possible via VBA coding; not by simply setting a property.

    Imagine that in an enterprise setting, there is a tight IT control on a existing SQL Server and the policy is to access and modify data through stored procedure ONLY. Presently, lot of VBA code must be written to "bind" updatable forms to it, in spite of the fact that sprocs are just basically glorified view and one-row modification (remember, IT policy). ADO allows you to define commands. DAO doesn't.

    Imagine being able to tell Access how to handle volatile primary key. Prefer sequences? Sure, set a property to get next value. Prefer custom stored procedure? No problem, too. That would cut down on errors causing #deleted or unnecessary queries (sent by Access in background) for figuring out which new record is really my inserted record.

    Each user stories on their own, aren't that big in themselves but put together, that is what we get if we were to make Access a better ODBC client, supporting and exposing more features, yielding many low-hanging fruits.

    An error occurred while saving the comment
    B. Clothier commented  · 

    One major omission from the list.... ability to parameterize the pass-through queries / stored procedures just like a native Access query.

    B. Clothier shared this idea  · 
  7. 63 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    Note that there is already an item that address this subject.

    https://access.uservoice.com/forums/319956-access-desktop-application/suggestions/15993274-make-access-a-better-odbc-client

    Note: A popular misconception is that ODBC is not "native" - in fact, SQL Server does uses ODBC natively and has for a while. However, Access' support of features that already exists in ODBC needs to be improved and that's a lower hanging fruit, IMHO.

  8. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Access (Desktop Application) » Other  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    I should point out that I've used Import to import MSysResources table to move a theme and images from one file to another, so it's not entirely without merits. I do agree, though that it could be done better. I'd probably sooner vote for an ability to filter the objects in Import List or to have a categorized rather than alphabetical listing so it's easier to keep MSys*** separate.

  9. 11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Access (Desktop Application) » Other  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    @Mark, that's true but there's also the possibility that they can just box it as custom classes for use within Access object library or similar avenues. That wouldn't require modifying the VBA and still achieve the goal of making it easier to work with nullable data types in code.

    B. Clothier shared this idea  · 
  10. 0 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Access (Desktop Application) » Other  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    FYI, Wayne already solved this with his vbWatchDog product which offers all and more.

  11. 160 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Access (Desktop Application) » Cloud  ·  Flag idea as inappropriate…  ·  Admin →
    B. Clothier supported this idea  · 
  12. 27 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  Access (Desktop Application) » Local Data  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    B. Clothier commented  · 

    I would probably go further with this idea. Instead of merely being a repository for manually entered notes, it can also auto-track the history of changes that a developer makes to the application. That might make it easy to keep track of what was changed, and thus give a good summary of what changed.

  13. 19 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    B. Clothier supported this idea  · 
  14. 11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    An error occurred while saving the comment
    B. Clothier commented  · 

    FYI - there is also this known issue that is a *big* PITA... From an old KB article..

    http://helpdoc-online.com/Microsoft_Knowledge_Base_October_2001_Access_en/ACC_Can_t_Trap_Specific_ODBC_Errors_OnOpen_Property.php

    (note that the title is misnamed - it says "OnOpen" but it's actually referring to "OnError".

    Addressing this pain point would go a long way toward making it easier to handle ODBC errors.

Feedback and Knowledge Base