Feedback by UserVoice

Mark Burns

My feedback

  1. 9 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Mark Burns commented  · 

    This request is relate to another existing topic. Can we merges these requests somehow?
    http://access.uservoice.com/forums/319956-access-desktop/suggestions/10130748-add-an-api-for-security-including-it-governance

  2. 12 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    Mark Burns supported this idea  · 
    An error occurred while saving the comment
    Mark Burns commented  · 

    I enthusiastically endorse this idea, but have no votes remaining to use for it.
    There are few things that Access does to frustrate you _more_ than to toss up that generic "xxx records not imported due to yyy type conversion errors, and zzz unique constraint violations..." etc.,. error message during a data import task.

    Sorry, but THAT IS JUST NOT ADEQUATELY USEFUL INFORMATION! We NEED to know PARTICULARS about WHAT record(s) an/or data failed to meet WHAT constraints! What records had type conversion failures on what values into what target fields?! When we get THIS data we then will have ACTIONABLE error correcting steps. Until then, it's a guessing game as to what isn't working.

    I would wish for you Access Dev Team folks to be under the gun to crank out a report for a meeting in 30 minutes, and with 10 minutes left to import a table and crank out a needed chart or report for the meeting, to be tossed into this particular error message heaven. Then you will begin to understand our frustration with this inadequate error messaging.

  3. 10 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
  4. 19 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
  5. 5 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    8 comments  ·  Access (Desktop Application) » Local Data  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Mark Burns commented  · 

    @Adrian,

    lol...so did the developers who first requested this enhancement about 20 years back. :-) Only the ACE and Jet angles are new to the subject here.

    An error occurred while saving the comment
    Mark Burns commented  · 

    @Adrian,

    The real rub here is backwards-compatibility issues with actual JET DAO objects (as opposed to the newer ACE DAO objects). Since the Access team now has control over ACE, they could implement something like this rather feasibly, but - what to do when the implementation code is handed a JET DAO object of the DAO.Worspace type that would have no implementation support for the new interface/methods/properties? I'd suggest that throwing a trappable error would be acceptable, but then if that happens while processing in an error handler already... So, would the answer be to add a descriptor.property to the DBEngine/Workspace.Database object to reflect a JET or ACE source object type?, which brings the problem back to the backwards-compatibie interface issue yet again. So, it's not such a cut-and-dried issue, sadly.

    An error occurred while saving the comment
    Mark Burns commented  · 

    Adrian,

    I wouldn't even care if they implemented this in a new interface, adding a Workspace2, Database2, DBEngine2 set of object identifiers which could polymorphically be accessed from the existing object handles (i.e. DIM oWkSp2 as DAO.Workspace2 : Set oWksp2 = <Existing .Worlspace object handle variable reference>) so that we could use the new/extended properties. ANYTHING would be better than NOTHING which is what we have now.

    An error occurred while saving the comment
    Mark Burns commented  · 

    Further, the TRANSACTION property data should reflect both whether a transaction is OPEN or not, but also the CURRENT NESTING DEPTH of all OPEN Transactions.

    Mark Burns shared this idea  · 
  6. 11 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    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
    Mark Burns commented  · 

    @Ben,

    How could they modify the VBA environment to accept the new (built-in?) class types as variables usable in calculations and normal arithmetic expressions without modifying the underlying implementation code to accept the new classes? Also, the rules of operation for expression evaluation would have to be modified (or at least reconsidered) to allow for the proper handling of the nullable concrete variable class types. So, I can't see them doing that as those changes would necessarily affect ALL VBA implementations across not only Access and Office, but all other VBA consuming applications (i.e. AutoCAD) out there.

    Now, understand that I'd still be all for that, of course, but it seems to me to fly too much against MS' previously stated position on NOT making any significant VBA changes/improvements going forward.

    An error occurred while saving the comment
    Mark Burns commented  · 

    I would SO vote for this idea, but it flies in the face of MS' previous declarations that they WILL NOT be seeking to seriously revamp or otherwise improve the VBA development environment, and in order for this idea to take root, new VBA Data types would need to be brought into existence, and it seems that they are not willing to think along those lines, unfortunately.

  7. 27 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    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
    Mark Burns commented  · 

    This idea is on a short path to something bigger and more substantive called Source Control / Version Control, and this type of documentation is an integral part of those subjects.

  8. 40 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    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
    Mark Burns commented  · 

    Further, if there is a problem with the default/installed printer driver, Access should automatically revert/default to "standard"/print-to-file defaults, rather than get hung up or fail to render screens or reports at all. Allow us to select the default printing data, like HCL , HTML, or a PostScript rendering for the default settings as a group of Access Option settings.

  9. 15 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    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
    Mark Burns commented  · 

    I'm guessing they are asking to replace Jet/Ace engine entirely with SQL Server's Local File store...or something along those lines (or, perhaps make Ace read/write into/with those SQL Server Local File Store databases - which have up to 10GB size limit iirc).

  10. 46 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    13 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Mark Burns commented  · 

    I understand the difficulty of this request as there is a tight relationship between the SQL view and the Query Designer views. I think it would be acceptable to allow the designer to obliterate the formatted SQL, so long as warnings were displayed before the changes were committed that will erase the formatted sql (and comments). Multiple statements could be handled in the designer simply by adding a vertical scrollbar to the right of the designer window (to scroll the multiple SQL statements). If the designer were to pop up a "Warning the SQL is in a formatted state, making changes in the designer will remove all SQL formatting." would be sufficient to allow people to decide what to do and how, or not. If you really wanted to go the extra mile, allow a special comment or something to bar the query editor from altering a formatted SQL statement. That way WE could control what things the query designed was allowed to "mess up" or not.

    Mark Burns shared this idea  · 
  11. 4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    Mark Burns supported this idea  · 
    An error occurred while saving the comment
    Mark Burns commented  · 

    Instead of a new function, add an optional parameter to NOW() for the desired timezone - and you can make the Current system TZ the default. This would permit all the existing now() calls to finction as-is, and allow the addition of parameters for timezones or UTC/Zulu or whatever.

  12. 4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    Mark Burns supported this idea  · 
1 3 Next →

Feedback and Knowledge Base