Migration Guide for Pre-OFM 2010.

1 Projects

*Mark of Schlumberger Copyright 1998 - 2012 Schlumberger. All rights reserved.

Copyright 19982012 Schlumberger. All rights reserved.

This work contains the confidential and proprietary trade secrets of Schlumberger and may not be copied or stored in an information retrieval system, transferred, used, distributed, translated or retransmitted in any form or by any means, electronic or mechanical, in whole or in part, without the express written permission of the copyright owner.

Trademarks & Service Marks

Schlumberger, the Schlumberger logotype, and other words or symbols used to identify the products and services described herein are either trademarks, trade names or service marks of Schlumberger and its licensors, or are the property of their respective owners. These marks may not be copied, imitated or used, in whole or in part, without the express prior written permission of Schlumberger. In addition, covers, page headers, custom graphics, icons, and other design elements may be service marks, trademarks, and/or trade dress of Schlumberger, and may not be copied, imitated, or used, in whole or in part, without the express prior written permission of Schlumberger. Other company, product, and service names are the properties of their respective owners. An asterisk (*) is used throughout this document to designate a mark of Schlumberger.

Schlumberger Private - Customer Use

iv

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

Contents
1 Information Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Schlumberger Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 About Schlumberger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Online Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Typestyle Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Alert Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Contacting Schlumberger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 2 Migrating to OFM 2012.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Using Versions 2009.2 and Earlier with OFM 2012.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Migrating Project Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Source Table Names and OFM Table Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Project Filters with Wildcard Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Migrating Linked Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Calculated Fields Used with Linked Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Saved Passwords for Linked Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Migrating Access Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 Migrating Shared Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 Migrating a Microsoft Access Home Data Source to SQL Server or Oracle . . . . . . . . . . . . . . . . . 2-12 Column Names When Migrating to Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13

Contents
Schlumberger Private - Customer Use

vi

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

1 Information Resources
In This Section
Schlumberger Product Documentation ......................................................... 1-2 Contacting Schlumberger ............................................................................ 1-3

Information Resources
Schlumberger Private - Customer Use

1-1

Schlumberger Product Documentation

Schlumberger Product Documentation

About Schlumberger Schlumberger is the leading oilfield services provider, trusted to deliver superior results and improved E&P performance for oil and gas companies around the world. Through our well site operations and in our research and engineering facilities, we develop products, services, and solutions that optimize customer performance in a safe and environmentally sound manner.

Online Documentation

Documentation is provided in the following electronic formats on the Schlumberger product CD: Adobe Acrobat PDF files Online help You must have Adobe Reader installed to read the PDF files. Adobe Reader installation programs for common operating systems are available for a free download from the Adobe Web site at www.adobe.com.

Typestyle Conventions

The following conventions are observed throughout this guide: Bold text is used to designate file and folder names, dialog titles, names of buttons, icons, and menus, and terms that are objects of a user selection. Italic text is used for word emphasis, defined terms, and manual titles. Monospace text (Courier) is used to show literal text as you would enter it, or as it would appear onscreen.

Alert Statements

The alerting statements are Notes, Cautions, and Warnings. These statements are formatted in the following style:

Note: Information that is incidental to the main text flow, or to an important point or tip provided in addition to the previous statement or instruction.

Caution: Advises of machine or data error that could occur should the user fail to take or avoid a specified action.

Warning: Requires immediate action by the user to prevent actual loss of data or where an action is irreversible, or when physical damage to the machine or devices is possible.
1-2 OFM 2012.1 Migration Guide
Schlumberger Private - Customer Use

Contacting Schlumberger

Contacting Schlumberger
Technical Support Schlumberger has sales and support offices around the world. For information on contacting Schlumberger, please refer to the information below. For Technical Support for SIS software: Schlumberger Support Portal: https://support.slb.com Customer Care Center e-mail: customercarecenter@slb.com Phone Support: - SIS Support (main) http://www.slb.com/contact_us/technology/sis/sis_support.aspx - Click here for Europe, Russia, and Africa Support - Click here for Middle East and Asia Pacific Support - Click here for North and South America Support

Information Resources
Schlumberger Private - Customer Use

1-3

Contacting Schlumberger

1-4

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

2 Migrating to OFM 2012.1

In This Chapter
Introduction ............................................................................................... 2-2 Using Versions 2009.2 and Earlier with OFM 2012.1 ...................................... 2-3 Migrating Project Filters .............................................................................. 2-4 Migrating Linked Tables............................................................................... 2-5 Migrating Access Queries ...........................................................................2-10 Migrating Shared Workspaces.....................................................................2-11 Migrating a Microsoft Access Home Data Source to SQL Server or Oracle.......2-12

Migrating to OFM 2012.1

Schlumberger Private - Customer Use

2-1

Introduction

Introduction
Note: The information in this book is the same as the information in the Migration Guide delivered with OFM 2010.1. If you have been using OFM 2010.1 and are upgrading to OFM 2012.1, you do not need to follow the instructions in this book. If you have been using OFM 2009.2 or an earlier version, and are upgrading directly to OFM 2012.1, you do need to follow the instructions in this book.
OFM 2010.1 enhanced the database engine technology used in previous versions of OFM. Since 2000, OFM relied on the Microsoft Jet Database Engine for creating databases, and for writing to and reading from those databases. Microsoft now considers the Jet engine a deprecated technology. OFM 2010.1 and OFM 2012.1 use ADO.NET, which is Microsoft's preferred database engine technology. We worked hard to make sure that when you migrate your workspaces to OFM 2012.1, the migration will be seamless as possible. However, your OFM workspace may be using Jet features that are not supported by ADO.NET, or are supported differently by ADO.NET. If so, this migration guide will help you to complete the move to OFM 2012.1 as quickly as possible.

2-2

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

Using Versions 2009.2 and Earlier with OFM 2012.1

Using Versions 2009.2 and Earlier with OFM 2012.1

When you upgrade a workspace, OFM 2012.1 does not change the existing Microsoft Access database. It only changes the .ofm file. When you upgrade your links as recommended with OFM 2012.1, if your workspace has linked tables then the original links remain in the original database. This means that you can continue to use previous versions of OFM with OFM 2012.1. The 2012.1 version of the .ofm file is not compatible OFM 2009.2 and earlier versions. If you plan to use these older versions of OFM with OFM 2012.1, choose a workspace migration option that allows you to do one of the following: Back up your previous .ofm file Save your new .ofm file with a new name To Migrate Workspaces from Prior Versions 1 2 Open OFM 2012.1. On the Workspace tab, click Open. Select the .ofm file, and then click Open. The OFM Workspace Upgrade Required window opens.

Select one of the options: To create a backup, select Backup old workspace to and then enter a new file name for your copy of the OFM workspace. To create a new name for your OFM workspace, select Rename new workspace to and then enter a new name for your .ofm file. To migrate without a backup or a new file name, select Migrate without backup or rename.

Click OK.
Migrating to OFM 2012.1
Schlumberger Private - Customer Use

2-3

Migrating Project Filters

Migrating Project Filters

If your workspace contains project filters, OFM 2012.1 may make changes to them when you migrate your workspace. The project filters will work as they did before; OFM only changes the filter syntax. There are two reasons for changing the project filters: 1. 2. OFM 2012.1 supports multiple data sources, so it cannot assume that every source table name is unique. ADO.NET requires different wildcard syntax than did the Jet Database Engine.

Source Table Names and OFM Table Names

Prior to OFM 2010.1, all local and linked tables were referenced within the Microsoft Access database. Access guaranteed that the source table names were unique within Access. With OFM 2012.1, you can connect directly to one or more data sources via ADO.NET, even if the tables in the sources are not linked to an Access database. In prior versions, project filters relied on unique names for the source table names. In OFM 2012.1, this may no longer be true. However, since every table enabled in OFM 2012.1 is guaranteed to have a unique OFM table name, when you migrate a workspace OFM 2012.1 substitutes the OFM table name for the source table name in the project filter syntax. At run time, OFM 2012.1 uses the OFM name to locate the corresponding source and source table name, and then uses that information to execute the project filter against the appropriate data source.

Project Filters with Wildcard Characters

ADO.NET supports SQL syntax that is slightly different than that supported by Access and Jet. For this reason, during migration OFM makes substitutions with project filters that use the LIKE clause and the Access-specific asterisk ( * ) wildcard character. OFM substitutes the percent sign ( % ) for the asterisk so the project filter can support the more standard SQL syntax for ADO.NET technology. ADO.NET no longer supports the question mark ( ? ), pound sign ( # ), and other wildcard characters, and OFM 2012.1 does not replace those wildcard characters when you migrate a workspace. If you have wildcard characters other than the asterisk, you must change your project filters.

Note: For more information about wildcards in ADO.NET, see the Wild Card Characters section of the Issues Migrating from DAO/Jet to ADO/Jet Microsoft article, at http://support.microsoft.com/kb/225048.

2-4

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

Migrating Linked Tables

Migrating Linked Tables

If your workspace contains linked tables that are enabled in OFM, when you migrate your workspace to OFM 2012.1 the Upgrade from Linked Tables Recommended window opens.

We recommend that you click OK, to upgrade the links. When you do this, OFM 2012.1 uses ADO.NET adapters to providers like SQL Server and Oracle, which are designed specifically for the best performance with those providers. However, you may need to take additional steps if either of the following is true: You added OFM calculated fields to your linked tables in OFM (see Calculated Fields Used with Linked Tables below) Your linked tables contain saved passwords (see Saved Passwords for Linked Tables on page 2-8)

Calculated Fields Used with Linked Tables

OFM calculated fields are not physical fields in the table. They are small pieces of SQL that OFM passes to the data source. The results are retrieved from the data source into OFM. Calculated fields often use SQL statements that are unique to the database provider (such as Access, SQL Server, or Oracle).

Migrating to OFM 2012.1

Schlumberger Private - Customer Use

2-5

Migrating Linked Tables

In prior versions of OFM, you could select or clear a Use pass-through queries for linked tables check box. This was a feature of the Jet Database Engine which OFM exposed.

Fig. 2-1

Use pass-through queries for linked tables check box in OFM 2009

ADO.NET does not support this feature. If your OFM 2012.1 data source is Microsoft Access, then all Access tableslocal and linkedwill be queried via the SQL supported by the ADO.NET adapter for Access. Similarly, if your OFM 2010.1 data source is Oracle, all Oracle tables will be will be queried via the SQL supported by the ADO.NET adapter for Oracle. As a result: If your linked tables' calculated fields currently use Access syntax (that is, you cleared the Use pass-through queries for linked tables check box), you must change the syntax for the calculated fields so they will work when you upgrade your linked tables in OFM 2012.1. If you do not upgrade linked tables with calculated fields and you selected the Use pass-through queries for linked tables check box, you may need to change the syntax for the calculated fields to work in OFM 2012.1.
Workspaces That Did Not Pass Through Queries

Prior versions of OFM exposed a feature of the Jet Database Engine which allowed queries to linked tables to be passed through to the underlying database. The Use pass-through queries for linked tables check box was selected by default. However, you may have cleared this check box if using pass-through queries were causing problems, or if you wished to take advantage of Jet syntax in calculated fields. If you did this, you must change the syntax for the calculated fields to work when you upgrade your linked tables in OFM 2012.1. Example: In this example, you: Have an OFM 2009 workspace that contains a table named PROD. The table is linked to Oracle.

2-6

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

Migrating Linked Tables

Cleared the Use pass-through queries for linked tables check box. Added a calculated field named WATER_ON to this table, and defined it as IIf( [WATER], 1, 0 ). Migrate your workspace to OFM 2012.1, and choose to upgrade your linked tables (that is, you clicked OK on the Upgrade from Linked Tables Recommended window). When you query data from the PROD table, you receive a SQL error. The IIf statement in the WATER_ON calculated field is Access-specific SQL syntax, and ADO.NET tries to evaluate the query via the SQL supported by the ADO.NET adapter for Oracle. To fix the problem, you could edit the calculated field and change the syntax to decode(WATER, 0, 0, NULL, 0, 1). This is equivalent functionally to the IIf statement, and is in a form supported by the ADO.NET adapter for Oracle.
Workspaces That Did Pass Through Queries

Prior versions of OFM exposed a feature of the Jet Database Engine which allowed queries to linked tables to be passed through to the underlying database. ADO.NET and OFM 2012.1 do not support this feature. If your OFM 2012.1 data source is Microsoft Access, then all Access tableslocal and linkedwill be queried via the SQL supported by the ADO.NET adapter for Access. When you migrate a workspace, you may choose to not upgrade your linked tables (that is, you may click Cancel on the Upgrade from Linked Tables Recommended window). However, you may need to change the syntax for the calculated fields to work in OFM 2012.1 if both of the following are true: You choose not to upgrade linked tables with calculated fields You cleared the Use pass-through queries for linked tables check box Example: In this example, you: Have an OFM 2009 workspace that contains a table named PROD. The table is linked to Oracle. Selected the Use pass-through queries for linked tables check box. Added a calculated field named WATER_ON to this table and defined it as decode(WATER, 0, 0, NULL, 0, 1). Migrate your workspace to OFM 2012.1, and choose not to upgrade your linked tables (that is, you clicked Cancel on the Upgrade from Linked Tables Recommended window). When you query data from the PROD table, you receive a SQL error. The decode statement in the WATER_ON calculated field is Oracle-specific SQL syntax, and ADO.NET tries to evaluate the query via the SQL supported by the ADO.NET adapter for Access. To fix the problem, you could edit the calculated field and change the syntax to IIf ( [WATER], 1, 0 ). this is equivalent functionally to the decode statement, and is of a form supported by the ADO.NET adapter for Access.

Migrating to OFM 2012.1

Schlumberger Private - Customer Use

2-7

Migrating Linked Tables

Saved Passwords for Linked Tables

Microsoft Access and the Jet Database Engine allowed OFM to save passwords with linked tables. Prior versions of OFM exposed this Jet feature. ADO.NET does not support this. For security protection, OFM 2012.1 will not save passwords for upgraded linked tables, or for newly-added data sources from databases such as SQL Server or Oracle. We discourage saving passwords, but there are two ways to save passwords to tables from data sources in SQL Server or Oracle: Using Microsoft Access Editing the .ofm file To Use Microsoft Access to Save Passwords to Tables

Note: If you perform these steps, OFM will use the ADO.Net provider for Access to access the linked table. OFM will not use the more-optimized adapter for SQL Server or Oracle.
1 2 3 Using Microsoft Access, create a link to the table in SQL Server or Oracle. Select the Access option to save the password. In OFM, on the Edit Schema Tables window, enable the table.

To Edit the .ofm File to Save Passwords to Tables 1 2 3 4 With a text XML editor, open the .ofm file. In the file, find the <DataSource> tag that describes the data source for which you want to save the password. Within the DataSource element, find the Connection property. Add the password string.

For example, this is a sample of an .ofm file altered (outside of OFM) to contain a saved password, with the password highlighted in blue text: <DataSource id="0"> <Properties> <Property id="ConnectionName">OFM5</Property> <Property id="Connection">Data Source=ORACLE10_PROD5; User ID=ofm5;Password=ofm5</Property> <Property id="UserName">ofm5</Property> <Property id="Driver">ORACLE</Property> <Property id="ServerName">ORACLE10_PROD5</Property> <Property id="WinAuth">NO</Property> <Property id="DefaultOwner">OFM5</Property> <Property id="MaxEntitiesInSql">500</Property>
2-8 OFM 2012.1 Migration Guide
Schlumberger Private - Customer Use

Migrating Linked Tables

<Property id="QueryTimeOut">-1</Property> </Properties> </DataSource>

Migrating to OFM 2012.1

Schlumberger Private - Customer Use

2-9

Migrating Access Queries

Migrating Access Queries

If your OFM workspace is currently attached to Microsoft Access queries with LIKE clauses and Access-specific wildcard characters, you may need to make changes to these queries for them to work with OFM 2012.1. ADO.NET adopted SQL, which has slightly different syntax than the syntax Access and Jet supported. For this reason, you may need to change SQL-based queries in Access. This is an example of a simple Access query which uses the LIKE clause with an Access asterisk wildcard character: SELECT MONTHLYPROD.UNIQUEID, MONTHLYPROD.DATE, MONTHLYPROD.OIL FROM MONTHLYPROD WHERE (((MONTHLYPROD.UNIQUEID) Like 'BLUE*')); In Microsoft Access, and in prior versions of OFM, this query would return records for all wells that began with BLUE. In OFM 2012.1, this query must use a percent sign instead of an asterisk: SELECT MONTHLYPROD.UNIQUEID, MONTHLYPROD.DATE, MONTHLYPROD.OIL FROM MONTHLYPROD WHERE (((MONTHLYPROD.UNIQUEID) Like 'BLUE%')); Microsoft Access will accept this new query syntax and allow you to save a query built with the % wildcard character, but Access will not return results if you run the query within OFM. Therefore, if you design queries using the LIKE clause in Access for attaching to OFM, we recommend that you design the query with the asterisk wildcard character until you see the results you want. Then, replace the asterisk with the percent sign before saving it for attaching to OFM. ADO.NET no longer supports the question mark ( ? ), pound sign ( # ), and other wildcard characters, and OFM 2012.1 does not replace those wildcard characters when you migrate a workspace. If you have wildcard characters other than the asterisk, you must change your project filters.

Note: For more information about wildcards in ADO.NET, see the Wild Card Characters section of the Issues Migrating from DAO/Jet to ADO/Jet Microsoft article, at http://support.microsoft.com/kb/225048.

2-10

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

Migrating Shared Workspaces

Migrating Shared Workspaces

You must migrate Shared Workspaces to OFM 2012.1 before migrating any workspaces that are sharing it. If you migrate an OFM workspace that is connected to a Shared Workspace, but the Shared Workspace has not been migrated yet, the following error message displays:

To Migrate Shared Workspaces 1 2 3 For the Shared Workspace, back up the workspace file. Migrate the Shared Workspace to OFM 2012.1. Migrate the workspaces that are connected to the Shared Workspace.

Migrating to OFM 2012.1

Schlumberger Private - Customer Use

2-11

Migrating a Microsoft Access Home Data Source to SQL Server or Oracle

Migrating a Microsoft Access Home Data Source to SQL Server or Oracle

In OFM 2012.1, you can migrate your entire OFM Access database to SQL Server or Oracle, eliminating the need for OFM to use a Microsoft Access database. For most users, there is little advantage to this. Microsoft deprecated the Jet Database Engine technology, but did not deprecate Access and the Access database. Since Access 2007, many improvements have been made to the Access database. With OFM 2012.1, you can create a new workspace in the new .accdb format supported by Access. However, for larger deployments of OFM, migrating from Access to Oracle or SQL Server might be advantageous. Individual OFM users could be connected to individual user accounts on these systems, and database administrators could develop ways to both share data with users, and manage the different sets of OFM results created by those users. OFM 2010.1 introduced the home data source concept. A home data source is the data source that contains the OFM-defined tables (such as pattern and forecast information). In OFM 2012.1, you can migrate to SQL Server or Oracle by changing the home data source to an Oracle or SQL data source. To Migrate an Access Home Data Source to SQL Server or Oracle 1 2 3 Upgrade your OFM workspace to OFM 2012.1. On the Upgrade from Linked Tables Recommended window, click OK. On the Setup tab, in the Tables group, click Schema. The Edit Schema Tables window opens. Add a new data source to your workspace: a. On the left pane, right-click a home data source or a database and then click Add. A new table is added to the OFM Representation tree. By default, the table is named NewItem and you must change the name. b. Enter a new name for your table and then press Enter. 4 Select the new data source and then click the Set Home button on the lowerleft corner of the window. The Set Home message opens, confirming whether you want to change the home data source and whether you want to copy the contents of your current OFM-defined tables to the new home data source. By default, if the new home data source contains OFM-defined tables, they will be used. If the tables do not exist, they will be created.

2-12

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use

Migrating a Microsoft Access Home Data Source to SQL Server or Oracle

To copy the contents of your current home's OFM-defined tables to your new home data source, select the Copy the OFM Defined Tables from Current Home to the New Home check box.

Warning: If you select the Copy the OFM Defined Tables from Current Home to the New Home check box, data in the new home's OFMdefined tables will be deleted before the copy.
6 Click Yes. The Edit Schema Tables window closes. OFM changes the home data source.

Column Names When Migrating to Oracle

The columns in some OFM-defined tables contain names that are reserved names in Oracle. If you migrate your home data source to Oracle, or if you create a new OFM 2012.1 workspace using Oracle as the home data source, the OFM-defined tables that are created will contain some columns with names that are different from OFMdefined tables in Access or SQL Server. For OFM 2012.1, there is no change to column names in OFM-defined tables contained in Access or SQL Server. These were preserved for company processes or tools that rely on the existing table schemas. The new column names are only for Oracle tables. The following table shows the differences between column names for OFM-defined tables in Access and SQL Server, versus those in Oracle. Table 2-1 Oracle Key Words Automatically Converted by OFM
Column Name in Access or SQL Column Name in Oracle

Date Name Row Top Type Option Index Comment Thread Size

OFM_DATE OFM_NAME OFM_ROW OFM_TOP OFM_TYPE OFM_OPTION OFM_INDEX OFM_COMMENT OFM_THREAD OFM_SIZE

Migrating to OFM 2012.1

Schlumberger Private - Customer Use

2-13

Migrating a Microsoft Access Home Data Source to SQL Server or Oracle

2-14

OFM 2012.1 Migration Guide

Schlumberger Private - Customer Use