How to store file attachments?
If the users of Access database connected to SQL Server (ADP actually) want to store various files as attachments to the records, how you guys implement it?
For example, if it's customer service application, they need to store estimates, emails, and such, pertaining to the case. If it's quality application, the pictures showing the problem. And so on.
For example, if it's customer service application, they need to store estimates, emails, and such, pertaining to the case. If it's quality application, the pictures showing the problem. And so on.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
In fact we already have one ADP application where I implemented storing on disk. Let's see... 18,423 items, 3.63GB, since 8/2008. Almost all files are PDF's (I trained the users that PDF is the only way to exchange and store the files). The largest file is mp4 video, 25MB
Now is the time to create another ADP application, also with attachments, so I decided to run this method by you guys.
Now is the time to create another ADP application, also with attachments, so I decided to run this method by you guys.
ASKER
...by the way, if you guys are familiar with ADP, and want to make a consulting buck, drop me a note. This new application somehow inflicts an internal resistance in me.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hey vadimrapp1,
Didn't even look at the asker when responding.
I wouldn't go the ADP route as there is no future in it. Essentially M$ with Access 2007 did not make an .accdp equivalent to the adp. The 2010 and below support. I haven't even checked if Acc 2013 will support ADP.
In your example of 19K documents in 3.63GB. If you can keep the 25MB or less limit then at 100K files you'll only be in the 1TB size, maybe 1.5.
Try handling that. I just think you're better off being external.
Didn't even look at the asker when responding.
I wouldn't go the ADP route as there is no future in it. Essentially M$ with Access 2007 did not make an .accdp equivalent to the adp. The 2010 and below support. I haven't even checked if Acc 2013 will support ADP.
In your example of 19K documents in 3.63GB. If you can keep the 25MB or less limit then at 100K files you'll only be in the 1TB size, maybe 1.5.
Try handling that. I just think you're better off being external.
ASKER
> I wouldn't go the ADP route as there is no future in it
Sure, but I go from the future defined by business requirements, and from what I see, at least in our co., whatever may appear on the horizon in the next 50 years, ADP still can do :-)
And I know no tool that would even approach ADP in programmer's productivity when creating sql server-driven applications (depends on one's personal skills/preferences, of course).
Sure, but I go from the future defined by business requirements, and from what I see, at least in our co., whatever may appear on the horizon in the next 50 years, ADP still can do :-)
And I know no tool that would even approach ADP in programmer's productivity when creating sql server-driven applications (depends on one's personal skills/preferences, of course).
whatever may appear on the horizon in the next 50 years, ADP still can do :-)
Not a problem -- just a suggestion.
But I still am thoroughly against storing binary files, no matter how small, in a DB.
Not a problem -- just a suggestion.
But I still am thoroughly against storing binary files, no matter how small, in a DB.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks everyone for the interesting discussion. Separate thanks (and extra points) to Bitsqueezer for FILESTREAM- based solution.
Its definitely not as cut and dried as you claim. In the example you describe I would absolutely agree - no question. But many systems aren't as cut and dried as that. It depends on the size of the items, the size of the application, and the budget for development. After having tried it both ways I tend to do a mix depending on how the data is used.
Its also not difficult to move them out of the DB later if the size does become an issue.