I am using SQL Server 2008.
I have a table (TBL_FILE) that stores user uploaded files in binary column. However users do not want to open our system to access the file. They want to have a folder (network drive, Web folder, local drive, local folder... are accepted) that maps to the table (TBL_FILE). So they can directly open the file directly in File Explorer.
The key point is they want to open files directly in File Explorer.
Is it possible to do that? And what kind of program I need to write to do that? And how to do security?
Thanks!
Alex
Have you considered writing an application that would prompt for a login, then present a list of files to the user in a friendly user interface? You could drop a shortcut to that application in the folder they want these files to live in.
If you must have shortcuts directly from the filesystem into your binary data fields, then you are going to have to be a little bit hacky. Depending on how often the files are updated, you can try one of these options:
1 - Write an application that will run as a Windows Service or as a scheduled job. Periodically check for changed binary data, and save it to disk. Disadvantage: the file system will only be updated at intervals, so database changes will not be immediately available.
2 - Write a trigger on the table that saves the binary file to disk. Fire the trigger whenever the row changes- preferably by monitoring a 'last modified time' or similar field, rather than checking the binary value directly. The trigger could fire a CLR stored procedure, or you can do it directly from T-SQL using the method described here.
Disadvantage: You have a potentially time-consuming trigger on the table.
In either case, security becomes the problem of the Windows filesystem. Just grant access to the folder to whomever should see the files.
Good luck!
after searching in google, I finally find a solution of this problem.
We could create a logical drive with .NET technology or other third party libraries. One of the libraries is Doken http://dokan-dev.net/en/.
Doken is able to let us to create a drive in computer and do the logic ourselves. It seems that it is able to map a folder to a table in Database. But I haven't tried it yet.
Thanks!
Alex
Related
I was using an Access file a colleague of mine created. They run it without issue on their computer all the time, but when I tried running it on mine, without modifying it, I had a value prompt window come up that isn't supposed to.
I think there's some sort of auto save feature on this file because even after closing it without saving, this message shows up and I'm no longer able to run the macro within the Access file. This file is stored on a shared network drive and file history isn't enabled on this drive nor on my machine. I'm not too familiar with Access and my colleague is on leave for some time. No one else seems to know Access very well either. Is there a way than I can restore the file or the queries/macro inside it to how they were before I opened it?
The basic answer is No. If something really was changed, there is no automatic history that can be used to recover changed settings or macros.
I realize it doesn't help to say anything now, but I am very surprised if there are no backups for the shared network drive. Is there no IT personnel that can assist? Regardless of whether or not you can get the file working, I would immediately make your own manual backup of the Access database file(s). (As long as you have a backup... or even better multiple backups, Access files can simply be restored from the original using file copy and paste.)
"Autosave" is an understatement with Access, because unlike a word processing document or spreadsheet which can be held completely in memory, a database file is constantly updated. There is no in-memory context for the database file as a whole. Access will almost immediately update the file once it is opened, simply because it manages things like file locks, etc. The database may have an Autoexecute macro or other code that runs automatically, but this may be accompanied by security prompts, especially if you haven't opened it on that computer before. For standard forms, changes to data on a form are saved to disk immediately and no "Save" button is required. Certain aspects of the database file should not changed unless explicitly told to do so, and these are usually design aspects not change accidentally.
I would like to know if there is a way to automate the process of saving a spreadsheet into an HTML file.
I have an OpenOffice spreadsheet that is located at a public file server inside my company´s LAN. A group of people work by editing and entering data into that spreadsheet, but others should only have read access. Since permissions policies can get a little bit complicated with OpenOffice, I thought it might be convenient for those who should only read the data to open the file in their web browsers by entering the route to the file or via a shortcut (specially since a lot of the read-only users are spreadsheet illiterates).
How can I achieve for this an HTML file to be updated every time the spreadsheet is saved by editing users, so read-only users can have the latest version?
Ideally, use a document management system that will keep older versions of the file to prevent mistaken edits by multiple people. Most DMS's provide some users with the ability to edit and others with the ability to read the document.
However, I once worked on a project where we used a large commercial DMS that was too complex for the read-only users. So we also ran a web server that provided read-only access to the documents.
Running a web server such as Apache HTTP Server, it is possible to do what you are asking even without a DMS. Provide a web form for people to submit edits to the document. When an edited document is submitted:
Save a copy of the old file.
Update the main version to the new file.
Run a command line job to convert the document to HTML.
Then read only users can view the HTML file by browsing to the web server.
Without a DMS or a web server, the best that can be done is to set file system permissions, as #mb21 said. That would certainly be easier to set up, and might be good enough depending on your needs.
I want to know which ways I can use to distribute an Access Database.
I'm developing an Access database split for distribute to many customers but I want to do something similar to an .exe file.
One file that contains:
Front-end
Database
Pictures
References
Templates
...
And other things.
I want one file that executes some instructions before opening my application, actions like: Create a folder in My Documents and copying files there,
check serial number of hard drive and continue if its authorized or stop it if not authorized, links FE and DB, encrypt database. (I have this coding in vba).
Can you help me?
You need a program that creates an installer (or setup program). Inno Setup is the first that comes to mind.
It even has its own SO tag. :)
Your setup must first check if Access (in a suitable version) is installed, and if not, install the Access Runtime.
I have a front-end Access 2007 apllication which talks to MySql server.
I want to have a feature where the application on the user's computer can detect that there is a new version on the network (which is not difficult) and download the latest version to the local drive and launch it.
Does anybody has any knowledge or exprience how this can be done?
Thanks
Do you actually need to find out if there is a newer version?
We have a similar setup as well, and we just copy the frontend and all related files every time someone starts the application.
Our users don't start Access or the frontend itself. They actually start a batch file which looks something like this:
#echo off
xcopy x:\soft\frontend.mde c:\app\ /Y
c:\app\frontend.mde
When we started writing our app, we thought about auto-updating as well and decided that just copying everything everytime is enough.
We have enough bandwidth, so the copying doesn't create any performance problems (with about 200 users).
Plus, it makes some things easier for me as a developer when I can be sure that each time the application is started, the frontend is overwritten anyway.
I don't have to care about auto-compacting the frontend when it's closed (and users complaining that closing the app takes too long...), and I don't have to deal with corrupted frontends after crashes.
#Lumis - concerning the custom icon:
Ok, maybe I should have made this more clear. There is only one batch file, and it's in the same network folder as the frontend.
The users just have links on their desktops which all point to the same batch file in the network folder.
This means that:
future changes to the batch file are easy, because it's only one single
file in one central place
we can change the icon, because
what the user sees is a normal Windows link
(By the way, we did not change the icon. Our app is for internal use only, and I'm working in a manufacturing company, which means that all but very few users are absolutely non-technical and couldn't care less about the icon, as long as it's the same on all machines and they know how it looks like so they can find it quickly on their desktop...)
Tony Toews has one: Access Auto FE Updater
It appears to be free, but I'm not 100% sure.
Lumis's option is solid, however if you want to check the version and only copy the database when their is a new version, have a 'Version' field in a back end table, and a 'Version' constant in a front end module. Keep these in sync with each new production release. Compare the table version against the version in the module when the main form of the front end database opens.
If they don't match, have the database close, but have the database call a batch file as the last bit of code to run as it's closing. The database should finish closing before the batch file begins it's copy process. If needed, place a minor delay in the batch file code just to be sure there are no file locking issues.
What are the benefits of choosing either:
a file in the user's home directory, e.g. ~/.myapp/config
using the user's gconf database
I already know a couple of things; storing data in the user's gconf database makes it a little harder for the user to copy those settings out and onto another account or computer. On the other hand, is it true that using gconf would be easier as the underlying data storage facilities are already sorted out, without you having to write your own configuration file handler?
I'd go with GConf.
However...
Perhaps if you are worried about users copying their settings in and out of the program, you should create import and export settings functions into your program? A user could then potentially save those settings in cloud storage like Ubuntu One or Dropbox and simply import their desired settings into GConf using the utility that you provide, regardless of the machine (even if they prefer to run from liveCD). Either way, very clearly indicate to the user where the settings are being stored. Many (but not all) Ubuntu users are comfortable backing up and restoring those configuration files by themselves using rsync or another backup utility.
Go with GConf. It was designed to store configuration for programs, and that is what you should use it for. Why should you re-invent the wheel from scratch when you have a perfectly good wheel making device in front of you?