Crystal Reports 10: Understanding Object Linking and Embedding (OLE)

The primary purpose for a report is to present database data to users in a form that's easy to understand. Crystal Reports gives you all the tools you need to do that. Sometimes, however, you want a report that does more than just present database data. You might want to include text from a word processing file, or data that resides in a spreadsheet, or a graphical image stored as a bitmapped image file. To allow the sharing of various kinds of information in different kinds of files, Microsoft developed the OLE (Object Linking and Embedding) architecture.

Reports that you create with Crystal Reports can serve as OLE container applications. That is, they can contain OLE objects that were created by other applications called OLE server applications. Microsoft Word and Microsoft Excel are examples of OLE server applications. You can take text from a Microsoft Word file as an OLE object — or take an Excel spreadsheet as an OLE object — and place it in a Crystal report.

Crystal Reports can also function as an OLE server application. You can define a report as an OLE object and place it into a Word text file, an Excel spreadsheet, or any other OLE-compatible container application.

OLE offers an unusual advantage: When you bring an OLE object into Crystal Reports and place it in a report, the object maintains a relationship with the application that created it. The nature of that relationship depends on whether the OLE object is static, embedded, or linked.

Static OLE objects

A static OLE object is a snapshot of an object that has been copied from the original application to the container application. You can place a static OLE object in a Crystal report, but after you put it there, you can't edit it or change it in any way (except to delete it). A static OLE object doesn't maintain any connection to the application that created it.

Embedded objects and linked objects

As with a static OLE object, an embedded OLE object is downloaded entirely to the container application, with an important difference: An embedded object is no snapshot. It has an "awareness" of which server application it comes from, and you can edit it within the container application. When you double-click an embedded OLE object, it becomes editable. The server application takes over the menus and toolbars to allow editing. For example, if you embed an Excel spreadsheet into a report, you can edit the spreadsheet from within Crystal Reports — using Excel menus and toolbars.

Any modifications you make to an embedded OLE object don't show up in the original file in the OLE server application. If you want to change the original, you have to do that separately.

Linked objects are like visitors; they don't actually move to the container application. What the container application contains is a pointer to the linked object (which remains in the server application). This link means that whenever the original object in the server application is updated, the linked object in the container application is updated too. Suppose, for example, that your server application is Excel, and you update the data in the linked spreadsheet. The next time you run your report in Crystal Reports, it pulls the latest data from the Excel file to display in the report.

Linking is best if your report must always reflect the latest data — and if you want the data in multiple applications to remain synchronized. The pointer also takes up less space than embedding a large spreadsheet or Word document, which makes the report faster to load. Reports containing linked objects are, however, less portable than reports containing embedded objects. For the link to work, the original server application must be present on the machine that's running Crystal Reports. By contrast, an embedded object is completely self-contained, needing no link to its source file or application.

dummies

Source:http://www.dummies.com/how-to/content/crystal-reports-10-understanding-object-linking-an.html