[AprilArchambault]

Ok, I love using the media feature for our donor and prospect records. (photos, news clippings, proposals, etc...all at the click of a button in one easy spot!) I want to confirm with someone that RE doesn't actually store these files in its system, but its rather a link to a location where the file is located in your directory. Am I right? If so, where can I find what the path is. We had a student scanning and adding media files to RE for us a while back...they're still working, but we have no idea where they were originally saved. I hope this isn't as clear as mud. haha...

[Melissa Siobhan]

RE can do either - imbed the files or create a link. Do you know which the student did?

[AprilArchambault]

Ok, this is making more sense now. Er..um I didn't know that until now. I suppose that's what checking the "link" box does...instead of embedding it, it links. I do not know which our student did, however I am guessing that he embedded them because his files were accidentally deleted and they still work in RE. Do you have any opinion on which option is best? To embed, or to link...that is the question. Thanks as always for your helpful nature!

[Kate Schandler]

April,

Excellent question. The answer, as with almost everything else in any Blackbaud program, depends on you.

If you embed the media files on the media tab they are saved within the database itself. This means they are easy to find and use. However, media files are HUGE files. Let me say that again, HUGE files. They will enlarge your database faster than you might like, and will slow down your records as each record with Media files runs through queries, exports, etc. If you go this route, Blackbaud says stay to less than 5 per constituent and you should be okay.

If you link the files, you save the hassle of size on your database- files can be linked and saved almost anywhere. However, you run into the problem of future portablity; where were your photos saved? Can you find them again? If you go with this solution, the best bet is to first save the pictures to a shared drive on the same server as your RE database, and then link to that file and only that file from the media tab. And never, ever, change servers. If those photos are ever moved (or linked to folders not on a server and not saved correctly,) the links within your database no longer work.

Let me know how it works out.
-Kate

[Andrew Gorczycki]

Kate,

I posted it some time ago under "Broken media link" thread Broken Media Links - how to find them?

lost media tab links - for future consideration
.....I had a little plan for this when the media tab links were implemented.
Very low tech in approach. The scanning is on network enabled Xerox X45. It has started as a scanning project of so called central file documents for high level donors to get digitalized copies of documents for easier access and secure backup reasons. After a pilot project it is continued as a part of a procedure supervised by Development Research Officer for contents and RE support in IT for technical and security reasons.

There are few rules though:

-documents and images in .pdf, .txt. doc .jpg format are stored on the file server separate form RE server. RE database keep only links to specific documents.

- one specific shared location with subject subfolders ie.: Research, Corporate, Individual, Foundations, Membership, Restricted/Confidential etc - reflecting Development Dept structure and data flow.

- name convention "Constituent ID_First Name_Last name(or Organization Name)_subject (ie. contract, bio,correspondence)_date(or date span)"

This way all this documents have unique location but also they can be accesed by relevant staff, according to their security priviliges, members even without access to RE or those in management who hate RE interface. Quite a few of them around actually.

The biggest advantage is that in cases like yours relinking is still possible and relatively low tech.

If you keep your name convention in order you can always list all files from folder to txt file and then dissect the name connvention using "_ " as delimiter and have a nice catalog of all scanned electronic documents. Not elegant but working solution.

Let me know if you want to know more about it.

Andrew Gorczycki
still in Guggenheim Museum but not for long

[Andrew Gorczycki]

I wonder if somebody with a better knowledge of RE table structure can shed some light on where the link is actually stored in RE database,
I would love to retrieve links in global report for all linked documents and images for change control purposes to have all incorrect links visible any time I need.

Andrew Gorczycki
still in Guggenheim Museum but not for long

[AprilArchambault]

Quote:

Originally Posted by Andrew Gorczycki

I wonder if somebody with a better knowledge of RE table structure can shed some light on where the link is actually stored in RE database,
I would love to retrieve links in global report for all linked documents and images for change control purposes to have all incorrect links visible any time I need.

Andrew Gorczycki
still in Guggenheim Museum but not for long

Me too me too!!

[AprilArchambault]

Quote:

Originally Posted by Kate Schandler

April,

Excellent question. The answer, as with almost everything else in any Blackbaud program, depends on you.
Let me know how it works out.
-Kate

Thanks Kate, for the helpful insight.

[DrewAllen]

Quote:

Originally Posted by Andrew Gorczycki

I wonder if somebody with a better knowledge of RE table structure can shed some light on where the link is actually stored in RE database,
I would love to retrieve links in global report for all linked documents and images for change control purposes to have all incorrect links visible any time I need.

Andrew Gorczycki
still in Guggenheim Museum but not for long

The link is stored as an OLE object in the Object field of the Media table. Don't ask me how to interpret the OLE data.

Drew

[SimonKoppel]

We had a discussion a while back on Media. One of the messages apparently coming from that was that embedding lots of Media shouldn't slow down Queries and Exports (presumably unless you are actually querying on Media information) because they are stored in different tables.

Knowledgebase says that files take up the same amount of server space if embedded in RE that they would take up externally. That can, as Kate says, be very large. If you're looking at scanning documents you should think carefully what format they will be stored in and how low-res you can get away with, to minimise file sizes.

[AprilArchambault]

Quote:

Originally Posted by SimonKoppel

We had a discussion a while back on Media. One of the messages apparently coming from that was that embedding lots of Media shouldn't slow down Queries and Exports (presumably unless you are actually querying on Media information) because they are stored in different tables.

Knowledgebase says that files take up the same amount of server space if embedded in RE that they would take up externally. That can, as Kate says, be very large. If you're looking at scanning documents you should think carefully what format they will be stored in and how low-res you can get away with, to minimise file sizes.

Noted. Thanks!

[Andrew Gorczycki]

Mellisa posted this way back in February 2008
Media linking problems
........
I found the positng on the TRE forum. I am hoping Shaun does not mind the re-posting here.

"I know it's probably not good form for me to arbitrarily chime in on
this list, but I see this question a lot and want to be clear about our
official position. You should *absolutely* store them in the database.
We actually store media in separate tables, so there is no performance
hit (or wasted cache memory) when querying constituents.

Do not worry about storage in SQL Standard or Enterprise, it is designed
to easily handle terabytes worth of data without breaking a sweat.

Storing links is a fragile solution with a legacy back to the early 90's
when database storage technology was not good around BLOB data, and disk
space was much more expensive.

If you absolutely MUST use links for whatever reason (for example if you
are using SQL Express), at the very least be sure to use UNC file names
as opposed to mapped drive letters.

I hope that helps.

Shaun Sullivan

Blackbaud, Inc."
__________________
Melissa S. Graves

Director of Development Services
The Village for Families and Children
The Village

........

[Melissa Siobhan]

LOL - a reposting of my reposting...

[Andrew Gorczycki]

Drew Allen
.....
The link is stored as an OLE object in the Object field of the Media table. Don't ask me how to interpret the OLE data.

.......

Shaun Sullivan

..........
You should *absolutely* store them in the database.
We actually store media in separate tables, so there is no performance
hit (or wasted cache memory) when querying constituents.

Do not worry about storage in SQL Standard or Enterprise, it is designed
to easily handle terabytes worth of data without breaking a sweat.

Storing links is a fragile solution with a legacy back to the early 90's
when database storage technology was not good around BLOB data, and disk
space was much more expensive.

If you absolutely MUST use links for whatever reason (for example if you
are using SQL Express), at the very least be sure to use UNC file names
as opposed to mapped drive letters.
..........


I more or less understand the concept of binary data streams and how they were handled in Access etc. which has an interpreter through integration with the MS Office libraries.

If linked document is not a copy of the original linked document or image but only a shortcut (and the proof is that when you change the original document you can see the changes accessing the document via Media tab link) why we can not list the shortcut path.
I understand it is a legacy issue but it doesn't make very much sense to store the path as binary.

If you open a document via Media tab and access the document properties you can see the original path to the location.

So it looks like the best solution to deal with the BB legacy problem and not create a problem of the dramatic increase of database size (and the wrath of IT Department) is to have:

-one remote storage sink for media type documents and images,accessible to RE and oviously RE users

-strong and consistent naming convention

-and if I am reading Shaun advise write use full UNC path

-I guess if somebody is really persistent and want the reporting the way around will be to store the whole UNC path including name in one of the fields accessible for query and reports which is either title or description.

Andrew Gorczycki
still in GuggenheimMuseum but not for long

[AprilArchambault]

I'm feeling slightly overwhelmed. I am not an IT person, nor someone who knows what UNC paths, storage sinks and BLOB's are. Could someone shed some light. (keeping in mind that not knowing these things does not make me an idiot...just a friendly everyday Raiser's Edge user looking to learn and understand a little more each day.)