Any potential problems with using attachments in access? (1 Viewer)

Would you recommend using attachments in an access database?

  • What's the point in having a database if you don't use attachments?!

    Votes: 0 0.0%
  • Yeah they work ok...

    Votes: 1 20.0%
  • Not really sure - i've had limited experience or having yet made up my mind

    Votes: 1 20.0%
  • This would be a bad idea

    Votes: 3 60.0%
  • This is why I'm going to be one of the first Mars colonists

    Votes: 0 0.0%

  • Total voters
    5

Danjo

New member
Local time
Today, 02:39
Joined
Dec 7, 2021
Messages
16
Hi,

Just wanted to get peoples opinion using the attachment field type. Supposing you are trying to build a super efficient database, keeping things as simple as possible to reduce issues later on - would having attachments in the database countermand that?

Obviously the size would go up depending on what is attached over time but i'd be interested to hear of other peoples experience with it.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 20:39
Joined
Feb 28, 2001
Messages
27,223
While attachments work, they tend to bloat the database. Having an external file link to something to be attached is FAR more efficient and doesn't so rapidly incur the problem of having 2 GB size limits for a DB file. File links - fully qualified file specs - chew up at most 255 bytes in a string. Attachements? KB or MB worth of stuff at a pop. Tends to eat free DB space in a heartbeat.

If you are speaking in general as a strategy, my answer stands.

If you have some specifics about WHY you wanted to use attachments, share them with us and we will perhaps be able to give better, more targeted advice.
 

Danjo

New member
Local time
Today, 02:39
Joined
Dec 7, 2021
Messages
16
Thanks. Its purely a hypothetical. I'm brand new to access so trying to get a feel for good practices.

I agree with using links as opposed to attaching, but this would introduce a further problem of enforcing link integrity if the files a moved or deleted. Just a thought
 

Danjo

New member
Local time
Today, 02:39
Joined
Dec 7, 2021
Messages
16
Certified Grandpa (3 grandsons). Retired and loving it. Must be doing something right 'cause my wife hasn't clobbered me yet.
:LOL: Amen to that!
 

MajP

You've got your good things, and you've got mine.
Local time
Yesterday, 21:39
Joined
May 21, 2018
Messages
8,554
The problem tends to be the user always says "I only plan to store a few attachments and not going to upgrade to another backend like sql server". Then pretty soon the few attachments is pushing up to the 2G limit of access. Then they want to migrate to SQL Server.

I always split my database into front end and backend. IMO it is very unwise not to do so. Makes maintaining it so much easier. So if I was to use attachments then they would go into a separate table in its own backend. This way if you have to address the size or upgrade then it is far simpler to deal just with one table in its own back end.
Also I would never ever use a hyperlink. Unmaintainable. I only store the file name. The path is stored in a settings table.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 02:39
Joined
Feb 19, 2013
Messages
16,629
, but this would introduce a further problem of enforcing link integrity if the files a moved or deleted
not really any different from moving, renaming or deleting a back end.

If these files are for specific use of the db (as an attachment would be), create a subfolder in the same directory of the BE to store the files in - can break down to further subfolders if required for whatever reason. Subfolder can be hidden to avoid the casual roving eye.

If they are not - so you have files all over the place for the convenience on non db users then potentially you have a problem with broken links. But if you are using attachments, in addition to the comments made by Doc and Maj you then have (in my opinion) the greater problem of synchronising changes.
 

oleronesoftwares

Passionate Learner
Local time
Yesterday, 18:39
Joined
Sep 22, 2014
Messages
1,159
While attachments work, they tend to bloat the database. Having an external file link to something to be attached is FAR more efficient and doesn't so rapidly incur the problem of having 2 GB size limits for a DB file.
I agree with the doc_man, but if the database will not have too many records and you want to avoid having images in separate files/folders from the database, then you can use the attachment field.

e.g A database for registering students in a school of 50 or less pupils, the attachment field can still be used here, so it all depends on the project.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 21:39
Joined
Feb 19, 2002
Messages
43,352
The Access interface for attachments is nice. The problem is that attachments are NOT supported by SQL Server so there is no upsize option. If you use the attachment data type, you are looking at a rewrite should you outgrow the very tine 2G size for Access

I tend to separate the path and the file name when storing the link to an external file. I also do not use hyperlinks for the same reason I don't use attachments - Access only.

Separating the path can save space in the individual records as well as eliminating the necessity to run update queries if the path needs to change. If I have different types of documents, I keep separate path definitions.
 

Isaac

Lifelong Learner
Local time
Yesterday, 18:39
Joined
Mar 14, 2017
Messages
8,778
Don't want to appear critical (as I've posted polls, it's hard to figure out the options and many people just say they didn't find one they liked) - but yet here goes: I didn't vote because no option reflects my opinion on the issue.

Attachments work perfectly fine. But, I recommend using them only in situations where their total volume (in total size of all attachments) will be quite limited. Otherwise, the database will become unnecessarily large and remember you have a very limited total size ....

Thus, in most situations I've had exposure to, a better idea is to store the file in a shared networked location/folder. Only store the full path to it (and of course, never a reference to a mapped drive as a rule of thumb, but the full UNC path). Then you can code to 'do' things with it when needed. When users want to view these files, I generally code to create a copy of the file only - to their local, then open that copy. This avoids unwanted edits. On the other hand, you may actually want edits.
Also, if you are worried about giving people full access to this folder, you could avoid that by using a Service Account and writing code to map a drive letter on-the-fly-with-credentials to access the files. (But that's a whole 'nother discussion, fraught with problems and will probably invite well deserved criticism - I'm just mentioning it).
Frankly, I pretty much always use this approach, if it's possible.

Finally, there is another scenario. If your database users span different networks and Sharepoint is the only connecting thread that exists (I'm in that situation now for certain projects), then Sharepoint attachments may be your best option, actually - and the folder option isn't an option at all.
Even in this case, I wouldn't recommend coding to open the attachment directly from Sharepoint - I'd code to download a copy, open for them to edit, save & close, and then delete the original and re-upload the edited version.

Lastly, upgrade to SQL potentiality. I agree with MajP that original intentions commonly don't match ultimate use cases. Thus, you should always plan to scale. However, if you are storing attachments in an Access database and someday have to do a migration, it's not difficult to write code that downloads all attachments with a reference to which record they belong to and then move to a network folder storage scheme. Possibly .5-2 hours of coding depending on how many attachments you have and what other columns you have to denote what is what - or any other conventions in use. Probably a drop in the bucket compared to your overall custom work that will be required to migrate to a GOOD sql structure.

That's the most well rounded advice I'm capable of on this subject, I think. Hope it helps.
 
Last edited:

MajP

You've got your good things, and you've got mine.
Local time
Yesterday, 21:39
Joined
May 21, 2018
Messages
8,554
If I am storing documents externally I do a couple of things.
1. I never have the user type file names in. This is always automated with file pickers. So the user browses to the file they want and selects it.
2. Once selected it is copied / moved to the correct folder.
3. It is then renamed to concatenate the Primary key of the related field. 'somefilename.jpg" to "1478_SomeFileName.jpg". Now it can be easily retrieved in code just looking for 1478.
4. I also clean up the name. I will get rid of spaces and lots of special characters. So " Some File 1.1.2 * .jpg" will end up like
1478_Some_File_1_1_2.jpg. You can save a file with almost any unicode character, but vba string functions do not work well with these.
5. I will store the original name for display purposes and use the new name to retrieve the file.
6. As mentioned the folder path is stored in a centralized location. If multiple folder paths are used then only a PK to a table holding the path is saved.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 20:39
Joined
Feb 28, 2001
Messages
27,223
For a while I used a picture organizer where I used a fully-qualified file spec - but it wasn't a HYPERLINK data field, it was just a short text field. If I wanted to see the pix, I had a form with an image control. Just loaded that FQFS to the image control's .Picture property and that was the end of that problem. For pictures, that works pretty darned well. For non-picture attachments, it would depend very much on the nature of the attachment because some attachment types would be trickier than others.

And by the way, I hold no faults with ANY of the methods described here because I'm a pragmatist. If it works for you, then it works for you and I don't need to rain on your parade unless there is a REAL problem lurking in something you said.
 

oleronesoftwares

Passionate Learner
Local time
Yesterday, 18:39
Joined
Sep 22, 2014
Messages
1,159
Just thinking now, is it possible to link images from any cloud service into access?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 20:39
Joined
Feb 28, 2001
Messages
27,223
Just thinking now, is it possible to link images from any cloud service into access?

You know, that's a good question. IF Access uses SMB protocols on image files, I think the answer is NO because the most common cloud servers do not support file transfer via SMB. They use HTTPS or SFTP or some other whole-file transfer method. But the truth is, I don't know what protocol is used for remote picture feeds. Unfortunately, I don't have a home setup that I could use to test this question.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 21:39
Joined
Feb 19, 2002
Messages
43,352
If you can map a drive to the cloud folder, the answer is yes. Otherwise, no. I have done this with FTP but not with the current "cloud" services.
 

mike60smart

Registered User.
Local time
Today, 02:39
Joined
Aug 6, 2017
Messages
1,913
This is one method
 

Attachments

  • HowToHandleAttachments_Demo.zip
    46.3 KB · Views: 198

oleronesoftwares

Passionate Learner
Local time
Yesterday, 18:39
Joined
Sep 22, 2014
Messages
1,159
If you can map a drive to the cloud folder, the answer is yes. Otherwise, no. I have done this with FTP but not with the current "cloud" services.
You are right, i just downloaded google drive application for PC, synchronized a local folder with google drive, and was able to use pictures from the local folder/google drive
 

GPGeorge

George Hepworth
Local time
Yesterday, 18:39
Joined
Nov 25, 2004
Messages
1,909
A friend of mine once got a really lucrative contract revising one of those "we're only going to have a few attachments" databases when they actually hit the 2GB limit and the thing stopped working. YMMV.;)
 

oleronesoftwares

Passionate Learner
Local time
Yesterday, 18:39
Joined
Sep 22, 2014
Messages
1,159
A friend of mine once got a really lucrative contract revising one of those "we're only going to have a few attachments" databases when they actually hit the 2GB limit and the thing stopped working
There are firms that consult mainly in the area of upsizing access db to ms sql, up scaling access applications, migrating access to web etc
 

GPGeorge

George Hepworth
Local time
Yesterday, 18:39
Joined
Nov 25, 2004
Messages
1,909
There are firms that consult mainly in the area of upsizing access db to ms sql, up scaling access applications, migrating access to web etc
I used to work for one. I did it as a consultant for several years. It's a good way to experience a wide range of businesses and database requirements. Some good, some more of a challenge.
 

oleronesoftwares

Passionate Learner
Local time
Yesterday, 18:39
Joined
Sep 22, 2014
Messages
1,159
I used to work for one. I did it as a consultant for several years. It's a good way to experience a wide range of businesses and database requirements. Some good, some more of a challenge.
Yes it exposes one and creates an avenue for one's creativity to be displayed, because cross-platform migration requires multiple skill set
 

Users who are viewing this thread

Top Bottom