ACC2010: date picker in restricted folder not available - ms-access

If an MS Access .mdb or .accdb file (assume front end db, data elsewhere) is placed in a folder where the user's permissions are limited to read & execute and the file is opened by ACC2007 or greater, the built-in date picker is not available. Is there a workaround other than elevating the user's permissions (either for that folder or moving to a folder where permissions are elevated)?

I have developed a complete datepicker solution that is not ActiveX driven and works in all current Windows environments. So, yes, there is a workaround. However, it's just not possible to explain it in this forum. It involves creating a new calendar form from scratch. Besides, a lot of Active X functionality in 2K7 is spotty and most people are moving away from it.

Related

SSRS URL Access setting a save location?

We have an SSRS 2012 report we have used URL access in order to automatically save to CSV upon running. This works fine, However, now I am told they want to force the report to save to a specific folder location for security reasons (they don't want it being saved to desktop) instead of allowing the user to save wherever. Is there a way to at the very least force a default location using URL access? Assuming this cannot be accomplished purely through the URL any suggestions for an alternative method?
You can find all of the applicable URL parameter commands here in the MS documentation.
That being said, there is no reference to the save location for the export render command that you are using to generate the CSV files. This makes sense because when a website serves a file to download to a browser, the location that the file is saved is actually a browser setting (IE instructions to change location)
I see two possible options:
Utilize a GPO to target the specific users and modify their registries to set the default download location (note that this affects everything they download). An example of this tutorial can be found here.
Use a Windows File Share subscription. If you view the report properties and click 'Subscribe', you can setup a file share delivery on a scheduled interval and export as a csv. Note that this is a schedule delivery though and obviously won't work if you users need to ad-hoc run the report on their timing.

Retaining File Path - Access/VB Common Dialogue DLL

So this issue appears to be unique to me as my coworkers aren't having any issues.
We have an Access DB that we use to upload files to SQL tables via forms. To choose the file for these forms there is a call in VB for a Common Dialogue DLL (me!File_Location=LaunchCD(Me) is the only code that launches the file explorer ). Whenever I upload a file, I have to remap to the folder I want every time as it reverts back to the base C drive for me. I am the only one with this issue as for everyone else it reverts back to the last folder they uploaded a file from.
I've found that people have this issue with internet browser uploading; but haven't come across anyone who is having the same issue as me with Access and it only affecting one person. If anyone could help it would be much appreciated as I use this program several times a day and it's beginning to get a bit tedious to have to remap to the folder ten times in a row to upload all files. Thanks!

Windows store app access file system

I'm developing a Windows store app and need to display files in user computer like in file explorer. Everywhere it says windows store apps only access "library" files and not other locations on the hard drives of PC. And I don't mean something like FileOpenPicker, I want to show file on may application like explorer.
What is the library I should use? System.IO class missing those methods on store apps. I know it is possible. Cos I have seen many applications in store has done that. Few examples are
https://www.microsoft.com/en-us/store/apps/file-browser/9wzdncrfj29m
https://www.microsoft.com/en-us/store/apps/my-explorer/9wzdncrfj0lm
Thanks in advance
Apps like the ones you mention typically use a FolderPicker to let the user pick the root of the file system and then remember that permission in a FutureAccessList for later use.
Your research was correct: apps cannot get general access to the file system. APps can declare access to the libraries, and app have automatic access to their local data, but anywhere else requires user permission via a picker or equivalent. See File access permissions on MSDN.

Directory sandboxed access for Google Drive / Dropbox API / RemoteStorage apps?

Is there a way to get sandboxed, user-selected directory access on any major file service without first getting read level access to their entire filesystem?
There's a lot of talk about "unhosted" static webapps that allow users to access their data from a 3rd party file service (Google Drive, Dropbox, their own server, etc.). The most notable effort I've found so far is remoteStorage.io, but there doesn't seem to be a way with any major provider to let the user select a directory and then use that as a sandbox without breaking their trust (i.e. getting read access to all their files first).
From the user's perspective, the webapp shouldn't have access to anything else on the remote file storage except the one folder the user grants it access to (for example, I might grant a text editor access to my FunnyJokes folder).
The current work around seems to be having the webapp force a specific folder name ahead of time ("this app wants access to /appname_notes"), but that rules out letting the user point it to where they may already have their notes.
Does anyone know of a nice way to do this with Google Drive, Dropbox, or the like?
The user experience that makes the most sense to me is something like...
User opens an unhosted webapp (for example, a basic text editor TextyApp). They click a button to connect with their data.
3rd party auth page appears (for example, Google Drive) and it says "The app TextyApp has requested read/write access to your files. Please select a directory to use."
Confirmation screen: "Grant read/write access to folder FunnyJokes for TextyApp?"
The page redirects back to the webapp with sandboxed accessed to the user-specified folder and the files within it.
This seems like how remote file storage should work, but I haven't found a way to do it yet. Any thoughts/suggestions would be great!
Cheers,
Adam
Edit: To clarify, I'm not talking about storing hidden "application data", but instead letting the user specify a particular directory to sandbox for use with a webapp that they may not want to give broader access to.
The Dropbox Apps API provides the ability to restrict any app using your API key to a single directory of your Dropbox account. So users could create an API key with access to a specific directory and then plug that into your app. However, that's not a user-friendly workflow.
I think the Dropbox Drop-Ins Chooser/Saver API might be close to what you want. The user is presented with a Dropbox file selection popup, and your app only gets access to the specific file(s) that the user selects.
With remoteStorage, sandboxed directory access is currently the default way for apps to request (and users to grant) access to the storage. However, users cannot manually select or enter custom directories during the connect phase.

Is there any way to have private data?

I'm aware of shortcut links. Looking for behavior similar to that of a native Google doc. File exists, possibly takes up storage, can be renamed/moved/deleted, but the data inside shouldn't be modified except by the app. Possibly, defining export formats/links.
I believe the answer is a simple "no" - Google Drive is for storing user files, not protected application data or configuration data. So you could put a file to a users drive, but only the owner of the drive can control whether the file is shared or changed. So they can edit it, you can't stop them, and there's no reason to think that'll ever be a feature in the future.
To have such control you will need to store such data on your own server, or some other such storage medium.
The only other thing that you would do with only Google Drive is encrypt the configuration file you store, for instance, so it couldn't be easily edited - but that's probably just a bad idea. If you must save a configuration file to a persons drive, bury it inside an application folder and sanity check it to ensure it isn't corrupt - but don't count on a person or application never opening and editing it. If it's something a person shouldn't be able to read or change, don't save it to their drive.
As of April 2012, application data is supported: What is the Application Data folder?.
"Export format links" could be done with Custom file properties, though, I'm unsure of what kind datatypes are supported for the value beyond the example string.