OLE objects saved as Scrap files

llandale - Thu Aug 27 17:47:17 EDT 2009
I don't know what a 'scrap' file is.

If you double-click on the Object Text to begin editing it, then single-click on the OLE, the bottom of the Edit Menu you find a Documement Object ... sub-menu, allowing you to 'Edit' it (edit in place), or 'Open' it (invokes the source application such as MS-Word). You should be able to save it from there.

However, if you inserted a bit map, perhaps cntl-PrintScreen then paste into the Text, you get a static bit-map not an OLE, there is no corresponding application and you cannot 'open' it.

• Louie

dasilvaa - Fri Aug 28 09:01:45 EDT 2009
Here's Microsoft's definition of a scrap file: http://support.microsoft.com/kb/138275 (an article that was not really informative regarding scrap filse and completely unhelpful in resolving my problem).

When I single click on the OLE object, I do get the Document Object menu but the behaviour for Edit and Open options is the same, the document opens up in Word both times.

However, the issue isn't editing the document, it's getting it out of DOORS completely. If it isn't too much trouble, can you try and see if you observe the same behaviour? Add a Word or Excel document as an OLE object to a module, and then drag and drop it to the desktop. Does it show up as the proper format (Word or Excel document), or does it save as a different icon with the filename of 'Scrap' and an extension of 'shs'?
Agustine

SystemAdmin - Fri Aug 28 09:43:52 EDT 2009
Yes, it is doing the same for me: DOORS 8.3 - insert an OLE object as icon. When I drag it to the desktop a Scrap file is created. Other way round it goes fine, you can drag a file from desktop and drop it into a DOORS object while editing.

dasilvaa - Fri Aug 28 09:01:45 EDT 2009
Here's Microsoft's definition of a scrap file: http://support.microsoft.com/kb/138275 (an article that was not really informative regarding scrap filse and completely unhelpful in resolving my problem).

When I single click on the OLE object, I do get the Document Object menu but the behaviour for Edit and Open options is the same, the document opens up in Word both times.

However, the issue isn't editing the document, it's getting it out of DOORS completely. If it isn't too much trouble, can you try and see if you observe the same behaviour? Add a Word or Excel document as an OLE object to a module, and then drag and drop it to the desktop. Does it show up as the proper format (Word or Excel document), or does it save as a different icon with the filename of 'Scrap' and an extension of 'shs'?
Agustine

Peter_Albert - Fri Aug 28 09:53:01 EDT 2009
But this behaviour is the expected one for all Windows programs. Drag a file from the desktop in an open Word file, this creates an OLE object in the Word file. Drag the OLE object back to the Desktop, and a scrap file is created.

SystemAdmin - Fri Aug 28 13:31:39 EDT 2009
OK, good to know that Windows behaves as designed :-)

kbmurphy - Fri Aug 28 18:47:44 EDT 2009
Why is nobody questioning the dasilvaa's question?

99.99999% of the time it is better to save OLE objects in DOORS rather than link to them.

Does the poster know that many people will just link to objects on their C:\ drive that no one else will be able to see or edit?

What about network access or Citrix or long-term planning in general? What if you have external access to DOORS? What if someone asks you to troubleshoot a link that you don't have access to? What if you want to do a partition and rejoin? What if someone MOVES THE FILE? Why use OLE at all when you could use an external DOORS Link to do the same thing with a blank object?

What do you have against users putting Word documents and Excel files into DOORS? This is certainly better than what you are proposing, unless you're in the .000001% environment.

I don't mean to come across as harsh, but while everyone gave dasilvaa the technical answer, no one asked why he/she wants to do such a thing to begin with.

SystemAdmin - Sat Aug 29 08:38:22 EDT 2009
I have to say that I am thinking in the same direction as the original poster: large scale use of OLE objects in DOORS leads to large scale problems with modules slowing down, exports being almost impossible etc.

External links would be one way to go, another maybe would be using same kind of document version management system and linking to it. This kind of approach would still leave OLE's with small (Excel) tables, different pictures, e.g. Visio diagrams, CAD drawings which are quite hard to store as documents - a whole Word document is easy to place in some external storage and link to it.

kbmurphy - Fri Aug 28 18:47:44 EDT 2009
Why is nobody questioning the dasilvaa's question?

99.99999% of the time it is better to save OLE objects in DOORS rather than link to them.

Does the poster know that many people will just link to objects on their C:\ drive that no one else will be able to see or edit?

What about network access or Citrix or long-term planning in general? What if you have external access to DOORS? What if someone asks you to troubleshoot a link that you don't have access to? What if you want to do a partition and rejoin? What if someone MOVES THE FILE? Why use OLE at all when you could use an external DOORS Link to do the same thing with a blank object?

What do you have against users putting Word documents and Excel files into DOORS? This is certainly better than what you are proposing, unless you're in the .000001% environment.

I don't mean to come across as harsh, but while everyone gave dasilvaa the technical answer, no one asked why he/she wants to do such a thing to begin with.

sammyc - Sat Aug 29 10:52:00 EDT 2009
I agree from my experience and must comment that Kevin speaks from pure experience with DOORS and likely from using other RM products that promote linking to objects outside of the database (not mentioned here ;o)....). The external links in DOORS are useful for some artifacts but OLE objects are best managed in DOORS - one reason is that DOORS is an OO database and can capture the changes made to OLE objects in the history records - very nice for active chng mgmt to OLE objects. Another problem is the linking to external artifacts in the file system that have to have a separate access control point for mgmt - this just complicates your environment w/o reason. And one additional reason is the inability to watch for changes to the objects if stored outside of DOORS which prevents the use of suspect links to manage the changes to the OLE objects.

dasilvaa - Mon Aug 31 10:04:06 EDT 2009
Thanks for the info folks. The reason I was wondering if there was a glitch was because scrap files are only created for MS Office products (Word, Excel, PowerPoint, Project etc.) while other files like TXT, JPG, ZIP are unaffected. It seems a little odd that the system would discriminate based on format or extension but I guess that's just the way it works.

Kevin, Ken: Pekka hit it pretty much on the head. We've found that adding OLE objects increases the size of our database and there have already been some performance hits (I should add that we're currently using Doors 8.1). Even beyond that, my organization has an existing enterprise system that already provides comprehensive document management, We have specific rules and guidelines regarding how documents are supposed to be life-cycled. These systems already provide linking mechanisms which work quite well with Doors (user access is setup in a similar fashion), so there really isn't a good reason why project teams using Doors should also store their documents there. For all of Doors' benefits, it is not a document management system.

Sammyc is right that Doors can capture the changes made to OLE objects via the history, but then we get into the issue where people who need to only view/edit the OLE objects have to get a Doors account and be granted access to the encapsulating module. Our thinking is that since we have a Document Management System, why not let it do what it does best and allow Doors to link to it and just focus on managing requirements.

It's what works for us.

Agustine

llandale - Mon Aug 31 10:35:13 EDT 2009
If your docs are managed elsewhere, then perhaps you should simply 'refer' to them from some DOORS object, perhaps ".. as per 'Environment Chart' Doc # ER58uIInf, table 3.1.5.4.", rather than having someone create a DOORS link to it.

• Louie

dasilvaa - Mon Aug 31 10:04:06 EDT 2009
Thanks for the info folks. The reason I was wondering if there was a glitch was because scrap files are only created for MS Office products (Word, Excel, PowerPoint, Project etc.) while other files like TXT, JPG, ZIP are unaffected. It seems a little odd that the system would discriminate based on format or extension but I guess that's just the way it works.

Kevin, Ken: Pekka hit it pretty much on the head. We've found that adding OLE objects increases the size of our database and there have already been some performance hits (I should add that we're currently using Doors 8.1). Even beyond that, my organization has an existing enterprise system that already provides comprehensive document management, We have specific rules and guidelines regarding how documents are supposed to be life-cycled. These systems already provide linking mechanisms which work quite well with Doors (user access is setup in a similar fashion), so there really isn't a good reason why project teams using Doors should also store their documents there. For all of Doors' benefits, it is not a document management system.

Sammyc is right that Doors can capture the changes made to OLE objects via the history, but then we get into the issue where people who need to only view/edit the OLE objects have to get a Doors account and be granted access to the encapsulating module. Our thinking is that since we have a Document Management System, why not let it do what it does best and allow Doors to link to it and just focus on managing requirements.

It's what works for us.

Agustine