Feedback by UserVoice

Nick67

My feedback

  1. 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 →
    Nick67 supported this idea  · 
    An error occurred while saving the comment
    Nick67 commented  · 

    And...
    I have discovered to my sorrow that you can only LoadFromText to the same version of Access as was used for the SaveAsText. ie, export everything from an Access 2003 mdb and you cannot pull it into an Access 2013 accdb. This is bad. Are not Access objects Access objects, period. Apparently not.
    Furthermore...
    When doing a SaveAsText / LoadAsText operation to clear any cruft from the file, all the objects get the date you did that operation as the 'creation date' Such operations should preserve the ACTUAL creation date of the object.

    There are just days when you really have to have this functionality. Quit hiding it. If files NEVER became corrupt, it'd fine, but they can and do go south occasionally.

  2. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Nick67 supported this idea  · 
  3. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    Nick67 shared this idea  · 
  4. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Access (Desktop Application) » Reports  ·  Flag idea as inappropriate…  ·  Admin →
    Nick67 shared this idea  · 
  5. 4 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 →
    Nick67 supported this idea  · 
    An error occurred while saving the comment
    Nick67 commented  · 

    Mega!
    We have this fine page
    https://msdn.microsoft.com/en-us/vba/access-vba/articles/reference-isbroken-property-access
    which can list for us all the busted references in a VBA project
    Nice! Yay!!!!!!

    But if you got dumb and opened a file with an uplevel version of Office (say 2016) that had early bound references to Excel and Outlook and built code like this

    'Public Function TestFix()
    'On Error Resume Next
    'Application.References.Remove References!Excel
    'Application.References.Remove References!Outlook
    'Access.References.AddFromGuid "{00020813-0000-0000-C000-000000000046}", 1, 5
    'Access.References.AddFromGuid "{00062FFF-0000-0000-C000-000000000046}", 9, 2
    '' Call a hidden SysCmd to automatically compile/save all modules.
    'Call SysCmd(504, 16483)
    'End Function
    '
    '
    'Public Function TestKill()
    'Dim hadbroken As Boolean
    'Dim myref As Access.Reference
    'Call TestFix
    'TestKill = False
    ''For Each myref In Access.References
    '' Select Case True
    '' Case myref.Guid = "{00020813-0000-0000-C000-000000000046}"
    '' If myref.Minor <> 5 Then
    '' Access.References.Remove References("Excel")
    '' TestKill = True
    '' End If
    '' Case myref.Guid = "{00062FFF-0000-0000-C000-000000000046}"
    '' If myref.Minor <> 2 Then
    '' Access.References.Remove References("Outlook")
    '' TestKill = True
    '' End If
    '' End Select
    ''Next myref
    '
    'End Function
    '
    'Public Function testremove()
    'Access.References.Remove References("Excel")
    'Access.References.Remove References("Outlook")
    'End Function

    You get to find out really quick that IsBroken is completely USELESS becuase you can't remove these busted references.
    PERIOD.

    Booooooooooooooo!!!!!!!!!!!!!
    Hissssssssssssssssssssss!!!!!!!!!

    What good is identifying the breakage with VBA if you can't FIX the breakage with VBA?

    Instead, we have to late-bind EVERYTHING to get down-level compatibility.
    This should have been fixed long ago.

    If the dev can guess that a reference could get broken, thew dev should be able to VBA code a contingency. Right now you can't. You only get to suffer.

  6. 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 →
    An error occurred while saving the comment
    Nick67 commented  · 

    'Whatever the App has permissions for and access to at any given time, can be exploited through the COM Automation security hole.' The App has the permissions and access that are granted to the logon. No more, no less.

    This is VBScript:

    sub UpdateDBversion

    dim myconn
    dim db
    dim rs
    Dim LocalSplit
    Dim splitstring
    dim PathToMDE
    dim x
    dim SQL
    PathToMDE = "c:\myfile.mdb"

    Set MyConn = CreateObject("ADODB.Connection")
    MyConn.Open "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TI_Data;Data Source=myserver\SQLEXPRESS"
    'MyConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\myfile.mdb"
    Set RS = MyConn.Execute("Select versionnumber from tblVersion;")

    splitstring = rs.fields("VersionNumber")
    LocalSplit = split(splitstring,".")
    x = UBound(LocalSplit)
    LocalSplit(x) = LocalSplit(x) +1

    MyConn.Execute("UPDATE tblVersion SET tblVersion.VersionNumber = " & chr(39) & join(localsplit,".") & chr(39))
    MyConn.close

    call UpdateVertxt(join(localsplit,"."))

    end sub

    You don't need MS ACCESS to get after things, you need permissions as the logged on user.
    If I have no rights to that table, or read-only rights, the VBScript fails. If I do have those rights, it works. But I am not using Access to update that version number, I am using VBScript. You can secure the front end through creating compiled apps. You can secure the backend through SQL Server, but at the end of the day if your logged on users are trying to hack your data using access granted them to do their jobs, you don't have an application problem, you have an HR problem.

    An error occurred while saving the comment
    Nick67 commented  · 

    I don't think this will ever happen, as it would break the current Automation model.
    If you need the data secured, that's what SQL Server Express Edition is for.
    If you need the file secured, that's what NTFS is for.
    If you have a user who you can't trust to keep their fingers out of the pies they don't belong in, yes that's a problem.

    This pales in comparison to the problem of the Nav Pain flying open, and exposing the tables, though.

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

    This is an IMMENSE pain in the arse since Access 2007 and is LONG OVERDUE for fixing. Access 2003 respected transparency upon printing of reports. Round images, such as engineers stamps could be placed and overlapped so that the non-transparent part of the images did not overlap and printed properly in Access 2003. Now the transparent area surrounding the image will blot out the non-transparent parts of images where they overlap.

    This is a downgrade from functionality that used to exist.
    Fix it.
    FIX IT!!!
    FIX IT ALREADY!!!
    It has been ELEVEN years, since Access 2007 broke this functionality.
    Come on already.
    How long do I have to keep Access 2003 in production because this is not being fixed?

  8. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    Nick67 supported this idea  · 
  9. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Access (Desktop Application)  ·  Flag idea as inappropriate…  ·  Admin →
    Nick67 shared this idea  · 
  10. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    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
    Nick67 commented  · 

    The Nav Pain is incredibly problematic.
    Every time you refresh table links via automation -- I have a dummy csv linked table that I replace with a stored csv file and then refresh to display charts -- the Nav Pain flys open. Every time I push out a changed front-end, the Nav Pain is open until the second time the file is opened, whereupon the code that hides it is honored. Every time the Nav Pain is opened via F11, it cannot be complete hidden again until the file is closed/opened again.

    This is painful. The Nav Pain is painful.
    Bring back the Database Window.
    That was far more useful UI to the professional dev than the flat file listed Nav Pain ever will be.
    My main app has north of 1200 objects.
    Who wants those in a flat, busy, visually undifferentiated column list?
    No one!

Feedback and Knowledge Base