How do I search in MS Access (ver 2010) for data in files attached to records? If I do a "Find" and specify text I KNOW is in an attached txt file to a particular record, there are no hits. While if I have the same data in a Text Field or Memo field, Access finds it. I understood from one of the Access help screens I found that it is possible to search attachments from within Access, but I have not been able to do this yet.
BTW, I did try using the query tool and searching for text I knew was in the attachment, but it was not successful, although it did find the same text within a memo field in another record.
Thx,
jmb
I'm fairly certain that there is no mechanism in Access to find records based on text within a file attachment. A bit of web searching found an earlier question here and the responses seem to agree that there isn't.
One reference from Microsoft here says
By using attachments, you open documents and other non-image files in their parent programs, so from within Access, you can search and edit those files.
but I think that statement could be misinterpreted. I believe what they meant to say was that
"...from within Access you can open an attachment in its parent program and then work on it as usual (e.g., edit it, search it, print it, and so on)."
You can use file system object, open the file as string and search sequentially. That's as close as you'll get
Related
I am trying to create a unique id and attach it to a LabVIEW file so that later I can read back that id and know I am looking at exactly the same file. I must be able to generate the id and read it back programmatically. The information must be hidden from the user accessing the file and persist across operating systems and storage mediums.
I was thinking of just adding it into the file 'comment' section, but it appears the Windows no longer supports file comments.
Any ideas?
I would suggest using the Set Tag method on the VI (with persistence) and saving multiple copies of the VI using the Save Instrument method, where each copy would then have its own unique value of the tag. Note that the method is defined as a scripting method, so you would probably need to enable scripting in the LV options to access it.
I don't think there's any API for enumerating tags, so there would be no way to find the value unless you know what the tag is called. Obviously, it's encoded somewhere in the VI file itself, and presumably it would be possible to extract a list of tags if you know the structure of the file, but that's not knowledge I would expect most students to have.
I'm not sure if you can call the set tag method from Python using an external connection to VI server, but certainly the LV code for this should be pretty simple - basically a for loop with ID generation, a couple of method calls and saving a CSV file so you can keep track of which ID belongs to which student. If you use existing IDs, you don't even need to generate and save the IDs.
I am trying to implement a document management system using Sharepoint. One major issue is that colleagues cannot find documents in the current setup (local fileserver). They have asked that we have a system that scans uploaded documents and automatically looks for keywords in them and then populates a "Meta" column.
I have had sort of success with OCR on image files, but getting keywords out of office documents (doc, xls etc.) I have had no success until now.
Is there a way to setup a flow to do this task for me?
any help is much aprechiated.
i tried "Get file metadata" and Azure "Text analysis", but it seems to take the raw data of the files (XML I assume) and returns that the document is to large to analyse.
There is something vague about this requirement - how is a keyword defined in a document?
Therefore, first obvious solution would be to assign keywords for each file upon uploading it. You may create a process for this with flow - have tasks, reminders and so on.
Automating this with OCR first means that you need to user OCR that works with MS flow you have only one choice - ElasticOCR. Then, in your flow
- feed the document content to the ElasticOCR action
- keep in mind that OCR is not 100% accurate
- analyze the generated text content according to your keyword definition
- finally write the meta back to the library in the corresponding columns.
Having worked on a similar requirement, we asked uploaders to publish their documents with a short abstract(column from the content type). The assumption is the abstract contains the keywords and is stored in a multi-line column - making it searchable site wide.
In cases when two attachments with the same filename are attached to a Notes Document, the second file is renamed internally to something like ATTXXXX. Even if the first filename is deleted and document re-saved, the internal filename remains cryptic.
There doesn't seem to be any way to retrieve the original Filename through back-end functions. I have looked high and low in LS but also in the C++ API, and could find nothing. It seems to be a trick that can only be done in the front-end. I am not sure where the information in the file icon graphic is stored, and whether it is accessible. In simple cases it would be possible to do a rename, I suppose (i.e. there is a single attachment and a single file icon graphic).
Could anybody confirm that this is, indeed a limitation of Notes or is there a cool way to solve this?
This is causing me some headaches whilst processing a large number of documents. My customer has trouble believing that there are some things that can only be done in the front end.
You should be able to get the original filename, even with duplicates.
It is not when the file is attached that the name is changed, it is when you detatch it.
You are probably using the .Name property, try the .Source property of the EmbeddedObject, that should return the original filename.
From the help:
If the NotesEmbeddedObject is an embedded object or object link, this property returns the internal name that Notes uses to refer to the source document.
If the NotesEmbeddedObject is a file attachment, this property returns the file name of the original file.
Syntax
To get: source$ = notesEmbeddedObject.Source
It's in the CD records for the rich text -- you will see it if you use NotesPeek to examine the contents of the rich text item. But I don't think it's accessible through the NotesRichText navigator class, so I'm pretty sure you would have to go the C API and parse through the CD records. Or, the MIDAS Rich Text API can probably get it, but that's third party software. I.e., not free.
I know that a Document Library in SharePoint 2007 has a multi-file uploader (an ActiveX control that -- and only if you have Office 2003+ installed) but how would I use this same feature with a normal (non-document-library) List item?
Uploading files to a normal List item involves clicking the "upload" link and browsing/uploading files one by one. Is there a better way than this? Surely there must be.
Jake
There is an approach I use, but there is no UI support for it. You may find it a bit tedious for onsey-twosey uploads, but it saved me hours once for serious bulk uploads.
The same WebDAV functionality that we get when using "Open with Windows Explorer" on a document library is available for a list.
Say I have a list at http://myorg.com/sites/Widgets/Lists/MyList.
I can open the list in Windows Explorer by going to the address \\myorg.com\sites\Widgets\Lists\MyList.
Attachments are stored in the sub-folder Attachments, which contains folders with numeric names (1, 2, 3, ... and so on). The numbers correspond to the item ID of the list item. Pick (or create) a folder with the ID corresponding to the item you want to upload to, and it's drag-and-drop from there.
Short of writing your own mulit-file upload web part I think you are going to be stuck with either one at a time (i.e. an attachment to the list item) or switch to a document library. Don't forget that you can customise your library to behave much like a list.
Why is it a problem to use a document library?
I seem to be making a habit of answering my own questions. Not sure if that's a good thing or not.
What I ended up doing was adding an "Upload Multiple Files" button to the toolbar which pointed to a custom ASPX page in the _layouts folder. This page displayed the ActiveX component used by a Document Library and the "post to" URL for it was the ASPX page itself. When posted to it looked for files uploaded and attached them all to the List Item referenced via URL parameters passed to it from the toolbar button.
It's discussed here:
http://weblogs.asp.net/nathanyorke/archive/2007/12/05/uploading-multiple-files-via-the-web.aspx
If I get round to blogging and fuller explanation on my own site I'll try and remember to post a link back here.
Jake
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.
You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.
What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)
This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.