Thanks for calling out this issue Subhabrata.
We are investigating this issue.
@Mark Burns – this is a different issue that we are looking into as well. Please post as a separate suggestion so people can vote on it and we can address.
Separate Item now posted as requested:
@Frank / Microsoft,
Isn't it a tad silly to have to UN-vote for something I DO support to add something new - only to then un-vote for what I just added to put my vote back where I had it? (and then leave the new suggestion/idea with NO votes?! ...or just forget that I supported another idea instead? The 20-vote limit is just silly to begin with, though I understand that it serves and anti-spam purpose.)
Oh, yes, I know that. They're there, but they're unusable by 3rd-party / out-of-process applications!
So, they're basically NOT there at the same time.
I am unable to post any new items due to the 20-vote (dumb) limit for voting on items. Once this limit is reached posting new requests is disabled.
This is only made worse by the affects of the different MS-Office installers. Traditional .MSI office installs do have this issue as stated. Click-To-Run (App-V based) installed Office apps have a WORSE issue in that the ODBC drivers APPEAR TO NOT BE INSTALLED AT ALL to the host OS.
You are complaining about something that is proverbially as old as the hills, and is a "symptom" of the normal operations of the Jet/ACE Database engines. In short, when a locking file is created upon opening a database file (and/or subsequently deleted) things ARE written to the database file, and the date updated is modified accordingly AND CORRECTLY for the OS/filesystem's rules of operations.
In short, if you really want this sort of capability, then move/copy all the database files to a folder with READ ONLY permissions (no Create/Edit/Delete permissions in the folder), and you can then open them with impunity and suffer no ill effects on the file's last updated datestamp. You WILL suffer the slings and arrows of Access complaining about the Read Only folder permissions, however.
This is a case of picking your poisons, I'm afraid.
10 votes4 comments · Access (Desktop Application) » External Data Connectivity · Flag idea as inappropriate… · Admin →
@Frank - you misunderstand the issue.
If you boy an o365 version that DOEs have Access...
but you select the Click-to-Run deployment installer, then oafer O365 (and Access) ARE installed, the ACE Engine ODBC Drivers are NOT VISIBLE to the Host OS.
This is the reason for needing the ACE 2016 redistributable package released (as a .MSI install) .... so that scripting tasks or other 3rd-party apps can SEE and USE the ACE Drivers for CTR-installed Office clients!
The ONLY way this could be done, given the current behind-the-scenes way that multiselect fields are implemented is if the Access USER had ADMIN RIGHTS and SCHEMA CHANGE rights to the *PRODUCTION* SQL Server database (at least at the point in time when a multiselect field were to be added to the database).
NO SQL Server DBA in their right minds would EVER allow such to be the case for a PRODUCTION database as it would generally be considered suicidal!
Please don't misunderstand me here. I'm all for enhancing MS Access security and convenience at the same time. I'd dearly LOVE to see some API improvements for security, such as an .OpenDatabasePassword property for the Access.Application (and/or .DBEngine) objects. (set the password property value before the .opendatabase call, and the password is cleared by the opendatabase call, but only at the end, so it persists during the call - and can be passed down to child databases such as those in linked tables.)
If there were a convenient way to leverage that via the access application command line also, GREAT!
...it's just that such methods are ripe with the potential for serious abuse/misuse - Dolly's excellent keys-under-the-doormat example being a wonderful one which underscores my concern about there potentially being unencrypted passwords in desktop shortcut command line strings - because we ALL just KNOW it WOULD HAPPEN like that in real life (we lazy/ignorant humans being who we are).
I'm only trying to make the point that such suggestions like this need deeper analysis, and the real answers here fall more into the "extend a security API to developers" category than they do as simpler request like "add a command-line password parameter"-type request.
This is a great idea...if compromised security is your goal. Allowing such passwords on the command line of a shortcut will achieve only 2 things. 1) your desired outcome; 2) the easiest path to compromised database passwords in recorded history (right-click on the shortcut and hit Properties and voila! the password is revealed to ALL!)
11 votes5 comments · Access (Desktop Application) » External Data Connectivity · Flag idea as inappropriate… · Admin →
Your posted Link is now broken.
Any chance that you have a better one?
I would vote for this if I had any free votes left! (*20* votes is a ridiculous limit)
The edit-ability of a set of crosstab results would be highly problematic in an of itself.
The UI is one issue, but the edit-ability of the underlying query results is actually a far more difficult challenge to achieve. This is particularly noticeable in that the key ID fields and similar associations are often lost/tossed aside in the shuffle of compiling the crosstab results, particularly when summaries or other domain functions are employed in generating the crosstab results.
8 votes0 comments · Access (Desktop Application) » Automating Tasks · Flag idea as inappropriate… · Admin →
17 votes2 comments · Access (Desktop Application) » External Data Connectivity · Flag idea as inappropriate… · Admin →
I would definitely vote for this if I had any votes left!!
That actually sounds like it could be a display driver issue, and not so much an Access issue. Have you checked out available updates for your display adapter lately?
ADDITIONALLY - Make the Access UI respond to the Browser magnification hotkeys Ctrl-+ and Ctrl-(minus/hyphen). Those of us users with poorer visual acuity issues really appreciate the on-demand freedom to scale up UI items in modern browsers this way - WHY CAN'T ACCESS (and other Office Apps) DO THIS TOO!?? ...or do you folks imagine that somehow everyone has perfect vision and/or our eyes don't get tired/strained as the day stretches on?
This request is relate to another existing topic. Can we merges these requests somehow?
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.
I would request that this idea (and the the votes for it) be merged into the other requests for general improvements to the Query Designer SQL view.
and here: http://access.uservoice.com/forums/319956-access-desktop/suggestions/10159107-sql-view-add-replace-to-edit-mode
This wish is a duplicate of items expressed both Here: http://access.uservoice.com/forums/319956-access-desktop/suggestions/10263849-provide-a-better-sql-editor and Here: http://access.uservoice.com/forums/319956-access-desktop/suggestions/10130526-allow-jet-ace-sql-to-support-multiple-sql-statemen
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.
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.
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.
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.
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.
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.
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.