Progress OpenEdge 11.5.0.0 Readme Ports: All Date: December, 2014 -------------------------------- Copyright (c) 1984-2014 Progress Software Corporation. All rights reserved. Read these On-line Release Notes ================================ It is important to read these on-line release notes. They are the exclusive release notes for this release. The on-line release notes are on the distribution medium as one text file, readme.txt. The readme.txt file includes a list of known issues followed by a list of the issues fixed in this release. In addition, the distribution medium includes the following HTML report files which list the issues addressed in this release - organized by version, issue number (CR ID), or product component. * PROGRESS_OE_ release# _VERSION.htm (Lists fixed issues by Version) * PROGRESS_OE_ release# _ISSUE.htm (Lists fixed issues by Issue Number) * PROGRESS_OE_ release# _COMPONENT.htm (Lists fixed issues by Component) --------------------------------------- PRODUCT NOTES for 11.5.0.0 a. ADE Tools and Runtime PSC00316376 : Correction to default dump names for schema tables ================================================================================ Dump and Load operations for the data of the _Partition* system tables now use the entire table name when the dump name is unknown. PSC00200793 : Initial value rules for logical fields in the GUI Dictionary ================================================================================ By default, when you create a logical field through the GUI Data Dictionary, it sets the Initial Value as the first value in the Format. For example, if the Format is "male/female", the Initial value defaults to male. The exception to the first item rule is when the format is "yes/no" or "true/false". For those cases, the tool uses the OpenEdge default value for a logical field, "no" and "false", respectively. PSC00172720 : Mandatory fields are not marked as NOT NULL during protoodbc ================================================================================ When running a pro-to-odbc migration against a DB2 data source, fields marked as "mandatory" in the OpenEdge database were being created in generated SQL script and the foreign data source without the NOT NULL syntax. This leads to a situation where these fields are null capable in the foreign database. To make DB2 consistent with the MS SQL Server and Oracle DataServers, the OpenEdge DataServer for ODBC will now set the NOT NULL constraint on SQL columns derived from mandatory fields for DB2 data sources. PSC00155578 : Generic comment deletion code removed from triggers ================================================================================ Deletion triggers have been updated to not generically remove comments, security allocation and multi-media records due to performance impact. A new ERWin trigger template db/af/erw/afercustrg.i has been provided that customers can use to re-generate their own triggers without the generic deletion code. Customers can also update their triggers with specific code to do the deletion in such a specific way that should not have any performance impact. PSC00240314 : Migrating Progress Dynamics to Release 11.0+ ================================================================================ Before attempting any migration, convert the physical database to Release 11.0+, using the proutil conv1011. Progress Software Corporation recommends making a backup at this time. Before migrating to Release 11.0+, Progress Dynamics currently using Version 2.1B must upgraded to Version 2.1B02. The following steps are the only supported path to migrate a Version 2.1B Repository to OpenEdge 10.2B: - Ensure the Repository is upgraded to Version 2.1B02 (db version: 020030). The migration does not work properly on earlier versions of the Repository. - Create a new shortcut for the Dynamics Configuration Utility (DCU), based on the existing shortcut from the install. - Modify the -icfparam parameter in the target. Change 'DCUSETUPTYPE=ProgressSetup' to 'DCUSETUPTYPE=Migrate21Setup'. - Run the Dynamic Configuration Utility (DCU) from this shortcut to upgrade the Repository from Version 2.1B02 to Release 11.0+. To migrate from Release 10.0B05 to Release 11.0+, follow these steps: - Ensure the Repository is upgraded to Release 10.0B05 (db version: 100005). The migration does not work properly on earlier versions of the Repository. - Create a new shortcut for the Dynamics Configuration Utility (DCU), based on the existing shortcut from the install. - Modify the -icfparam parameter in the target. Change DCUSETUPTYPE=ProgressSetup to DCUSETUPTYPE=Migrate100Setup. - Running the DCU from this shortcut upgrades the Repository from Release 10.0B05 to Release 11.0+. To migrate from Release 10.1A02 to Release 11.0+, follow these steps: - Ensure the Repository is upgraded to Release 10.1A02 (db version: 101002). The migration does not work properly on earlier versions of the Repository. - Create a new shortcut for the Dynamics Configuration Utility (DCU), based on the existing shortcut from the install. - Modify the -icfparam parameter in the target. Change DCUSETUPTYPE=ProgressSetup to DCUSETUPTYPE=Migrate101ASetup. - Running the DCU from this shortcut upgrades the Repository from Release 10.1A02 to Release 11.0+. To migrate from Release 10.1B03 to Release 11.0+, follow these steps: - Ensure the Repository is upgraded to Release 10.1B03 (db version: 101101). The migration does not work properly on earlier versions of the Repository. - Create a new shortcut for the Dynamics Configuration Utility (DCU), based on the existing shortcut from the install. - Modify the -icfparam parameter in the target. Change DCUSETUPTYPE=ProgressSetup to DCUSETUPTYPE=Migrate101BSetup. - Running the DCU from this shortcut upgrades the Repository from Release 10.1B03 to Release 11.0+. To migrate from Release 10.1C to Release 11.0+, follow these steps: - Ensure the Repository is upgraded to Release 10.1C (db version: 101201). The migration does not work properly on earlier versions of the Repository. The migration will also work for service packs 1 and 2. - Create a new shortcut for the Dynamics Configuration Utility (DCU), based on the existing shortcut from the install. - Modify the -icfparam parameter in the target. Change DCUSETUPTYPE=ProgressSetup to DCUSETUPTYPE=Migrate101CSetup. - Running the DCU from this shortcut upgrades the Repository from Release 10.1C to Release 11.0+. To migrate from Release 10.2A to Release 11.0+, follow these steps: - There were no updates made to the Repository between 10.2A and 11.0, and so no migration is necessary. To migrate from Release 10.2B to Release 11.0+, follow these steps: - There were no updates made to the Repository between 10.2B and 11.0, and so no migration is necessary. PSC00178641 : DCU enforces MinVersion with migrations ================================================================================ If a setup XML file has migration setup types (defined by having a migration_source_branch session property with a non-blank value), then a check is performed to ensure that the DB version sequence matches that of the MinimumVersion in the Database node of the setup_type. If these 2 versions don't match an error is raised and a message shown. This message is a new message and has a code of 'MSG_cannot_migrate', and appears in the shipped setup101B.xml. If customers have created their own setup.xml files, they need to add this message to all the setup types contained in those XML files. PSC00174297 : Dynamics translated application: performance problems on login ================================================================================ Support has been added for a session property called "cached_translations_only" which is set via the session definition (in the XML file and/or repository). In the absence of such a property in the session, the default is YES (the historical value). If cached_translations_only is false, then translations are not retrieved at startup, but rather on demand when an object is translated. PSC00162290 : Static Object Deployment Tool - Option to generate source listing ================================================================================ The Deploy Static Objects tool has the ability to produce a listing file of all the files that are packaged into a deployment produced by the tool. The listing file is specified in the UI before the deployment starts building. If no listing file is specified, then the listing will not be produced. A default value is provided by the tool, and is for a file called 'listing.log' in the session's temporary directory. The listing file consists of the following fields, tab-delimited: File name Relative path Deployment type Design-only flag This functionality can be used to determine which files are required for compilation on 64-bit platforms. A Dynamics client is only supported on Windows, which is a 32-bit platform, and customers may connect to an AppServer running on a 64-bit platform; in such a case the code would need to be compiled against the 64-bit platform, and the listing file will give the ability to determine which files are required. PSC00140234 : Notes on using the Deploy Static Objects tool ================================================================================ When deploying static objects using the Deploy Static Objects tool, please note the following: 1) You must specify the following extra directories in the Deploy Static Objects tool, in order for a standard Progress Dynamics WebClient install to work: adeicon ry/img adm2/image adeicon.pl can be used instead of the adeicon directory, but you must manually copy this file into the target directory. These image directories are not required for a server install (AppServer of Web). 2) You must manually copy the adm2/dyntreew.wrx file into the target directory, for WebClient installs. 3) You must manually copy adecomm.pl into the target directory for a WebClient install. PSC00314904 : The adm2/dyntreeview.w SmartObject only works in 32-bit installs ================================================================================ The adm2/dyntreeview SmartObject is implemented using a 32-bit OCX control. An error message about the OCX not being registered or moved will be thrown if you attempt to run or drop this SmartObject on a container in a 64-bit install. PSC00240288 : The DynamicsVersion session property must be manually updated ================================================================================ If you are working in an OpenEdge release later than 10.2B, the DynamicsVersion session property may be set to the wrong release number. This property is not automatically updated. To workaround this issue, modify $DLC/src/dynamics/db/icf/dfd/update_dynamics_version_property.p so that the value of the DYNAMICS-VERSION preprocessor is set to the relevant OpenEdge release number (11.2, for example). Compile this file and copy to $DLC/gui, which is important because the DCU does not run against source code. PSC00224776 : ADM2 default data management ignores orphaned/unlinked SDOs on Viewers ================================================================================ A SmartDataObject (SDO) placed on a Viewer without being linked to a data source or to a field is not included in the container's first request to the AppServer and will thus not get any data. This was not the case in old releases of OpenEdge (before v10). You can uncheck the Appserver Aware option in the Procedure Settings of the container to get the old behavior. This makes the SDOs revert to the old request behavior with one AppServer request per SDO. Note that this can add a substantial overhead to the data retrieval from the AppServer. Alternatively, you can move the SDO to the SmartContainer and use the pass-thru link mechanisms to make it accessible to the Viewer, or override initializeObject in the Viewer and call openQuery in the SDO. This approach may require one extra AppServer request specifically for the SDO. PSC00219897 : Dynamic SDO with join require calculated fields to be defined in table order ================================================================================ In a Dynamic SDO based on a join, calculated fields will behave incorrectly under these circumstances: - Both tables in the join have calculated fields defined in the Repository's entity definitions. - Both tables also have one or more of these SDO Entity calculated fields included in the SDO. - The calculated fields from the right-hand table of the join appear before those of the left-hand table in the list of fields in the SDO. Symptoms include incorrect formatting and incorrect initial values being provided, as well as calls to the SDO data logic procedure failing with errors relating to temp-table schema mismatches. PSC00207823 : dynlaunch.i fails in thin client with DATETIME, DATETIME-TZ, RAW or ROWID param ================================================================================ Calling a PLIP using dynlaunch.i fails in a thin-client environment if the procedure call includes DATETIME, DATETIME-TZ, RAW or ROWID parameters. The client will report this error: Mismatched number of parameters passed to routine name . (3234) The AppServer agent will report these errors: BUFFER-FIELD was not found in buffer ttSeqType. (7351) Lead attributes in a chained-attribute expression (a:b:c) must be type HANDLE or a user-defined type and valid (not UNKNOWN). (10068) The workaround is to implement calls with these data types to run as external procedure calls on the AppServer. e.g. RUN xxx on gshAstraAppServer (INPUT ...) Alternatively, you might add CASE statements for the 4 data types in obtainInitialValueField in adm2/caller.p. (This has not been tested, but is assumed to be the problem.) PSC00195316 : **Widget ID n not unique ( widget-name ) error for recursive Dyn TreeViews ================================================================================ The "Runtime Widget-ID Assignment" tool assigns default gap values for the imported SmartObjects. These default values should work without problems in most cases. But, for Dynamic TreeViews with structure nodes, the default gap value of 2000 for "TreeNode" might not be large enough. Since the nodes are created at runtime according to the database data, it is impossible to know how many tree node levels are going to be created in the Dynamic TreeView. If this happens and the default gap value of 2000 is not enough, that default value should be increased as specified in the "Application Development Environment (ADE) Addenda" Web paper in the "Widget IDs for ADM2 and Progress Dynamics" section. PSC00194792 : Toolbar never creates a Band more than once per toolbar instance ================================================================================ The toolbar creates only a single instance of each Band for a toolbar instance. However, the Repository allows multiple instances of the same Band on a toolbar. Before Release 10.1C, the toolbar created the multiple instances of the same Band, but the second instance had no menu items. In Release 10.1C, the second instance of a Band is ignored completely. PSC00180829 : DynLookup limit on number of joins may vary on DataServers ================================================================================ In Release 10.1C, the DynLookup supports a join with up to 18 tables instead of 10. But, this limit might not apply when using a DataServer, because there also is a limit decided by the size of the ROWIDs in the tables. The ROWIDs of the tables are added to an indexed RowIdent field and the ABL has a limit on the size of an index. Starting with Release 10.1B, as long as -tmpbsize 4 (default) or larger is used, temp-tables use large index keys and can store up to 1970 characters. This means that, in theory, you can store and index up to 16 ROWIDs returned from MSSQL server ( 16 * ( 116 + 1 ) - 1 = 1871 characters for rowids + separators). The different DataServers will return ROWIDs with different lengths, so the limit will vary. If this limit is an issue, then you can edit the af/app/afgettemp.p procedure and remove the following index definition. ---- hTT:ADD-NEW-INDEX("idxRowIdent":U,FALSE,FALSE). hTT:ADD-INDEX-FIELD("idxRowIdent":U,"RowIdent":U,"asc":U). ---- The index is used in certain reposition operations on the client. Removing it has an affect on performance, but this might be unnoticeable or acceptable since the operation is done on the temp-table on the client. PSC00170305 : UndoChange action added to all tableio toolbars ================================================================================ Beginning with version 10.1B all shipped toolbars and tableio bands contain a new UndoChange action. This action replaces the old Reset action as the default in these toolbars. This constitutes a behavior change (label and accelerator) for existing applications that use the shipped toolbars or bands, since the caption is changed to "Undo" instead of "Reset" and the accelerator is changed to "CTRL-Z" from "ALT-R". The new UndoChange action defines some of the translatable text needed for the context sensitive text in the admmsgs.i include, message number 97. Customers that use the shipped toolbars or bands and want to remove the new action and get the old one back need to customize the class or toolbar. Customers that already have specific toolbars might need changes either to be able to use the new action or to remove it. To remove (hide) the new UndoChange action and get Reset back in shipped toolbar or band: ------------------------------------------------------------------- The Reset action is already present in the toolbar, so in order to make the Reset into default, the UndoChange needs to be added to the comma-separated HiddenActions property. Existing customer toolbars -------------------------- Existing customer toolbars may or may not get the new UndoChange action. If the toolbar or menu is defined with the "Tableio" category or one of the tableio bands, then the action is added automatically. But, many toolbars add tableio actions specifically in initAction() or initMenu() overrides in order to control the order and add rules. The "UndoChange" will need to be added to these. customized initAction --------------------- Since the getTableioUndoNew may need to load the actions if it is called from a visual object before the toolbar is initialized, the toolbar initAction has been changed to setIsActionsLoaded(true). Overrides of initAction that do not call super must add the same call, using dynamic-function or the {set~ include. PSC00167044 : The Export to Excel functionality removes leading zeros from character strings ================================================================================ The Export to Excel functionality removes leading zeros from character strings. PSC00162037 : IndexInformation property only contains information for primary table(s) ================================================================================ The IndexInformation property has been changed to only contain index information for the table(s) that are uniquely represented in one row in the SDO query. The default table(s) are the EnabledTables or the first table for read-only SDOs. The getIndexInfoTables function determines which tables' info is added to the property. This is not implemented as a property, but can be overridden if different behavior is needed. If you want the old behavior all data objects, then add a custom version that returns the value from getTables (all tables in the query). PSC00161048 : Changes to how decimal values are managed in dynamic combos ================================================================================ There were several problems in previous releases developing decimal dynamic combos with default flag values that contain a numeric decimal point and deploying with different numeric formats. Default flag values were always stored in the format used during development. This prevented deployment to numeric formats other than the one used for development. Either errors displayed and no data displayed in the combo or incorrect data was stored in the repository for the None or All option. With 2.1B01, 10.0B03 and 10.1A this has changed to store default flag values with American numeric format. They should be entered in the SmartDataField maintenance tool using the session's format but the tool will replace the numeric decimal point with a period in the stored value. At runtime, any stored periods in the data are replaced with the current session's numeric decimal point. A fix program runs as part of the DCU Upgrade to convert existing default flag values for decimal dynamic combos to American format. The DCU must run in the format that was used to develop dynamic combos. The fix program writes a message to the log file for each default flag value it attempts to convert. It writes a message when a value is converted successfully or writes a message if the conversion fails. Review the DCU log file after the upgrade and manually correct any failures. Any failures that are not corrected may not behave properly at runtime as the runtime has changed to attempt to convert stored American formats to the format of the running session. There are several Dynamics objects in the repository that store blank default flag value instance attributes and give messages in the log file. These are for the cbSCMTool dynamic combo on the following viewer objects: gsmsxgenviewv gsmsxotviewv gsmsxpmviewv The messages for these objects are expected and you can ignore them. Any dynamic combo instance attributes stored in static viewer code in your application must be converted manually to American numeric format. PSC00159054 : assignNewValue w/ invalid values behaves different in new lookup API ================================================================================ The old and new lookup APIs behave differently when passing invalid value parameters to assignNewValue if the lookup key field is different from the lookup displayed field. With the old API (pre-2.1B/10.0B02 behavior and 2.1B/10.0B02 behavior with keep_old_api set to TRUE), passing an invalid key field value or an invalid displayed field value to assignNewValue displays blank in the lookup field when assignNewValue is invoked. If changes to the record are saved, blank is stored in the record's key field. With the new API (2.1B/10.0B02 default behavior), passing an invalid key field parameter displays blank in the lookup field when assignNewValue is invoked. If changes to the record are saved, the previous value displays in the lookup field and the value is not changed in the record's key field. Passing an invalid displayed field parameter displays the invalid value in the lookup field when assignNewValue is invoked. If changes to the record are saved, the previous value displays in the lookup PSC00158854 : Widgets on static SmartDataBrowser are not enabled on dynamic containers ================================================================================ When a static SmartDataBrowser contains other objects on its frame, those objects are not enabled when the static SmartDataBrowser is run on a dynamic container. When that static SmartDataBrowser is run on a static container, those objects are enabled. PSC00158601 : BaseQuery must have NO-LOCK after WHERE ================================================================================ A child SDO loses parent filter criteria if its BaseQuery has the NO-LOCK option before the WHERE criteria. When two SmartDataObjects are linked in a parent/child relationship, with or without a SmartBusinessObject, the child SDO might lose its filtering by the parent SDO. In previous versions, this happened if the child SDO was generated by the Object Generator with Follow joins turned on. This generated a BaseQuery with NO-LOCKs before the join criteria and caused the ADM to add the foreignfield criteria to the query incorrectly. As a workaround, opening and saving the SDO in the AppBuilder alters the BaseQuery to put the NO-LOCKs after the join criteria as expected by the ADM. PSC00158372 : DynCombo support for a DataObject as data source does not include static SDO ================================================================================ The option to define an SDO DataSource for a DynCombo is not supported for static SDOs. PSC00158340 : Sharing data object, browse and viewer out of sync showing data ================================================================================ The support for SharedData does not actively refresh viewers or browse viewports when data is changed by another DataObject. To refresh a browse, you must currently scroll the record out of the viewport. To refresh a viewer, you must currently navigate to another record and back. Note that a viewer on a hidden page does not refresh itself if it is on the same record as when it was hidden. So, in this case, it does not help to navigate to another record and back in the browser. PSC00157892 : SDO Cache does not include Auditing & Comments tick-information ================================================================================ The data caching and data sharing support does not always cache auditing and comment information. This information is retrieved only for certain instances and would only be cached if the actual object that did the initial server retrieval was set up to include this information. Data objects that retrieve their data from the cache may thus be unable to show the correct tick-mark in the toolbar if the initial server request did not include this information. PSC00157071 : stripLookupfields is not used in the new lookup API ================================================================================ In previous versions, the stripLookupFields procedure was called on each display to figure out if the SmartDataFields could be resolved by the viewer's DataSource. The new lookup API does not use this procedure. PSC00156968 : Setting of BaseQuery in initializeObject requires synchronization of QueryWhere ================================================================================ If any other query manipulation has been done before changes to the BaseQuery are made, you need to synchronize QueryWhere and possibly the QueryString. If the BaseQuery is set in an initializeObject override before SUPER, you might also need to synchronize QueryWhere in an SDO without any custom query manipulation. The only cases where BaseQuery can be set without synchronizing the QueryWhere are on the client (AsDivision = 'client') and in dynamic SDOs on the server (AsDivision = 'server'). Static SDOs calls setOpenQuery, which calls setQueryWhere, from the main block (query.i) when connected to the database. Dynamic objects that are connected to the database will call prepareQuery from createObjects. Background: The BaseQuery is the design-time, fixed part of the query. It is part of the object definition. The design philosophy is that runtime query manipulation can be done without violating the integrity of this part of the expression. Consequently, the BaseQuery should not be changed after any query manipulation has been done. However, it is quite common for applications to need to set this when an SDO instance is launched. (For example, to filter data on department or company key based on the userid.) Various examples and documentation have shown and stated that this can be done in an initializeObject override before the call to SUPER. In particular, older documentation examples showed this being done with setOpenQuery, which also synchronizes the physical query by calling QueryWhere. This was a problem on a client since setQueryWhere used to always prepare the physical query. setQueryWhere has since become more lightweight, but setOpenQuery still calls the server and should still be avoided in an AppServer session. PSC00156174 : Translation tool does not include SmartDataBrowser search field ================================================================================ The optional search field of a SmartDataBrowser doesn't show up in the translation window to allow you to add a translation. PSC00156171 : The SmartDataBrowser sort profile is not used with SBO data-sources ================================================================================ The sort profile saved for a SmartDataBrowser with a SmartBusinessObject as its data-source is not used upon restart. PSC00155989 : Changes in how Dynamics Window dimension profiles store WINDOW-MAXIMIZED ================================================================================ Progress Dynamics windows now store the WINDOW-MAXIMIZED state together with the previously stored dimensions in the user profile. The state is stored as a 5th entry in the profile value. In previous versions, this state just overwrote the old profile. If you close a maximized window and no dimensions have been saved previously, the window still stores "WINDOW-MAXIMIZED" as the only entry. With the new behavior, a window can store the WINDOW-MAXIMIZED state without loosing the stored dimensions for the previously saved WINDOW-NORMAL state. The next time you launch the window, it displays maximized. But, when the WINDOW-NORMAL state is applied, the window resumes its previously stored size. PSC00154960 : Dynamic Lookup maintenance window does not destroy its maintenenance SDO ================================================================================ The Dynamic Lookup maintenance window does not destroy its SDO and associated Data Logic Procedure Whenever you open the maintenance window of the dynamic lookup from the dynamic lookup browse, the system launches a new instance of the maintenance window's SDO and its associated DLP. However, these objects are not destroyed upon closing the maintenance window. PSC00154765 : Error messages for child SDO not returned when CLOB involved ================================================================================ A detailed error message may not be returned to the client while adding a record to a SmartDataObject under the following circumstances: - the SDO is running on AppServer - the SDO contains large object fields - AutoCommit is false (commit is used to commit multiple updates at once) The client does receive an "update cancelled" message but should have a detailed error. The detailed error is written to the AppServer log file. This situation is more likely to occur with an SDO that is part of a SmartBusinessObject. PSC00154671 : SmartFrame objects stored with .w in object name may need two translations ================================================================================ For SmartFrames or SmartWindows that are launched from a static container, the object name for Title and Page Label translations is resolved from the procedure:FILE-NAME without path and extension. Therefore, SmartFrame objects that have the .w extension in their Repository object names might need two translations, one without the extension for usage in static containers and one with the extension for dynamic containers. PSC00151672 : CallerProcedure, CallerObject, and CallerWindow are not set in createObjects ================================================================================ The Session Manager's launch in Progress Dynamics sets properties like CallerProcedure, CallerObject, and CallerWindow in the launched container. These properties are set before the container is initialized and can thus be used in an initializeObject override. However, they are not intended for use during the construction (the execution of the main block) of the container. The createObjects call is typically done as part of the construction. However, in previous releases, static non-window containers, like SmartFames and SmartDataViewers, did call createObjects from initializeObject allowing these properties to be used also in createObjects. Now, createObjects is called during the construction of almost all containers. If a createObject override uses these properties, it is unlikely to work. Any logic referring to these properties in createObjects should be moved to an initializeObject override instead. Moving this logic to initializeObject should not cause any change in behaviour. PSC00150794 : Read only SDO tables can be specified to remain NO-LOCKed during transaction ================================================================================ The NoLockReadOnlyTables property can hold a comma-separated list of read-only (non-updatable) tables that should remain NO-LOCKed during the transaction. A value of 'ALL' means that all read-only tables should remain NO-LOCKed. Note that read-only tables defined by this property also are excluded from the optimistic lock check of changes. PSC00144084 : Error 4054 (.. does not fit..) if ToolbarDrawDirection is "vertical" ================================================================================ The Dynamics layout manager does not handle toolbars where the ToolbarDrawDirection is set to 'vertical'. PSC00140279 : Static browsers/browsers in static windows don't get Repository column labels ================================================================================ Browsers running in static windows linked to a static SDO on an AppServer will not get the column-label from the Repository's EntityField. Instead, the browser gets the column-label from the database schema. This problem also applies to any static browser. PSC00140138 : A single toolbar cannot switch navigation between SDOs and SBOs ================================================================================ In a paged container where a SDO is the Data-source of a SBO, you cannot use a single toolbar to navigate both the SDO and the SBO. PSC00140135 : Loss of data when changing page while browse is in add ================================================================================ When adding a new record in a browser that is part of a tabbed user interface, the entered data can be lost or appended to the next record in the browser under the following conditions: - The browser is the update source for an SDO. - The user did not enter all of the required fields in the browser row. - The user selects a different page before saving the new record. PSC00133069 : ADM2 does not support the READ-ONLY attribute on browse columns ================================================================================ The ADM2 does not support setting the READ-ONLY attribute directly on browse columns as a way to disable fields. Field enabling is controlled by the EnabledFields property, that is, you make columns read-only by removing them from the enabled fields list. This is not considered to be a bug. Dynamic browser columns are all read-only at start up, so it would be very difficult to implement a solution to detect if the READ-ONLY attribute has been set in initializeObject. PSC00130471 : New records can be duplicated when reading new batch if added while batching ================================================================================ If new records are created that sort higher than the last record in the current batch, the new record is duplicated when a batch includes the new record. To prevent this, either ensure that the user is at the last batch when adding the new records that will get key values that sort higher than the currently last record or avoid batching when such records can be created. PSC00130387 : RowObjUpd.ChangedFields is obsolete ================================================================================ Prior to Version 10.0A, the RowObjUpd.ChangedFields field was used to figure out which fields to save in an SDO. This is now obsolete and no longer used. The SDO now figures out which fields to save to the database tables based on a comparison of the before-image and the changed record. The ChangedFields field is not used in any logic, except for a call to bufferCollectChanges, which updates this field. Since it does not capture all changes, this update is not reliable and the method will be deprecated in the future. PSC00129126 : Avoid changing Foreign Keys in Web Objects with joined queries ================================================================================ When you use the Detail Wizard to create a Web object that contains a join, do not make the foreign key field updateable. If you change the value of the foreign key in a record, the next stateless request might not be able to find that record. When this happens, you get an error that the query could not reposition to that record. If your application needs the ability to update the value of the foreign key in a joined query, you must make sure that the list of ROWIDs in the "CurrentRowids" attribute contains ROWIDs of the newly joined table, instead of the originally-joined table. PSC00128303 : Static data objects do not get initial value from Repository ================================================================================ Static SDO proxies ( sdo _cl) do not get the INITIAL-VALUE from the Repository's EntityField DefaultValue at run time. The temp-table's INITIAL-VALUE attribute is a read-only attribute that is compiled into the SDO temp-table definition from the SDO include. PSC00124754 : Print Preview and Export to Excel do not work when the data source is an SBO ================================================================================ Print Preview and Export to Excel options available on various browse toolbars are not supported for visual objects whose data sources are SmartBusinessObjects. These options will do nothing when chosen. PSC00121785 : Record level transaction hooks must be implemented in the Data Logic Procedure ================================================================================ You must implement a static SmartDataObject's record level transaction hooks (create*, write*, and delete*) in the Data Logic Procedure. They will only fire from the SDO if the SDO does not have a Data Logic Procedure. PSC00156243 : Help cannot be mapped to static container run from the AppBuilder ================================================================================ It is not possible to map help for a static container that has been run from the AppBuilder. The container must be run from the Dynamic Launcher to map help for it. PSC00173682 : Progress Dynamics can't find the help file during AppServer sessions ================================================================================ When the help file is set in the "security control" window, Progress Dynamics can't find the help file using the help-menu-item in an AppServer session. PSC00171808 : Translated labels and widgets on same row but different column ================================================================================ When translating static viewers where KeepChildPositions=Yes, translated labels now use the existing label's width only. Also when translating static viewers, the label's font, rather than the widget's font, is used to determine the width of the label. The translation of simple (LIST-ITEMS) combo-box labels is now supported for dynamic viewers. When translating dynamic viewers with KeepChildPositions=Yes, the label moves to the bottom (back) so that it doesn't overlay any widgets to its left. The label is not truncated, unless it is longer than the space available. PSC00168877 : The DataView does not support Dynamics Comments and Auditing ================================================================================ There is no default support for Comments and Auditing when DataViews and ProDataSets are used. The following error is returned when attempting to save a comment for a DataView: BUFFER-FIELD RowUserProp was not found in buffer dataset-buffer-name .(7351) The Server Interface implementation could define a RowUserPropfield in the entity temp-table to store the information needed to trigger Auto Comment and show tick marks in the Dynamics toolbar's Auditing and Comment actions, similar to how the SDO handles it. Using this field might make it easier to use existing Repository Manager APIs and reuse existing SDO code. Note that the Auditing and Comment information is stored with delimiters in the field. This makes it difficult to use outside of the ADM and difficult to populate. The population have to be done for each record and will likely affect performance. PSC00155275 : Info for all users sent to client ================================================================================ When a user attempts to login in a client-AppServer configuration, the entire list of users is sent from the AppServer back to the client. This may be an expensive operation when there is a large number of users in the repository. To reduce this overhead, adding the session property "abbreviatedUserTable" to all client and AppServer session types and setting its value to "YES" will result in only the user that is logging in having his data shipped across from the AppServer, thereby reducing the traffic. PSC00153575 : Static SmartDataFields (e.g. SmartSelect) cannot be translated. ================================================================================ SmartSelect objects are not presented for translation in the Translation window at runtime. The work around is to enter translations of SmartSelects in the Translation Control tool. The same naming convention as for Lookups is used. You must specify the Widget Type as 'FILL-IN' and the Widget Name as 'fiLookup' in all cases. You must enter the Object Name as viewer-name : field-name . If the static SmartDataViewer containing the SmartSelect is used in a static container, you must enter the file name of the viewer, including the extension (.w), in the Object Name. If the viewer is used in a dynamic container, you must enter the object name of the viewer, without any extension. This is an example based on a viewer for the Warehouse table using a SmartSelect for the 'State' field. The file name of the viewer is 'warehousesdv.w'. Translation for use in a static container: Object Name: warehousesdv.w:state Widget Type: Fill In Widget Name: fiLookup Translation for use in a dynamic container: Object Name: warehousesdv:state Widget Type: Fill In Widget Name: fiLookup PSC00201988 : Error: The Root node code must be specified. (AF:1) when creating Dyn TreeViews ================================================================================ When entering data in the "Dynamic TreeView Builder" tool, you must enter the "Object filename" value first. If you do not enter the Object filename first, you see the "Root node code must be specified. (AF:1)" error upon saving the data. PSC00200646 : Error 7452 in Dynamics Dataset Export Filter ================================================================================ Customers using European numeric settings might see the 7452 error when pressing the filter button on the Dataset Export screen. PSC00155024 : Cascading security allocations does not work for Data Security ================================================================================ The option to cascade security allocations from a profile user does not work for Data security. PSC00151136 : RTB: Problems when dyn object and super proc in different module ================================================================================ When modifying a dynamic object where the dynamic object and its super procedure were created in different product modules, the following error may occur: The product module product-module1 and the product module product-module2 must be the same. (AF:110) PSC00146842 : Error 560 Generating Objects From SDO ================================================================================ Error 560 (Entry outside the range of list) is raised when the Object Generator is used to create dynamic objects from a prebuilt SDO when the SDO has been created by the Object Generator, and has subsequently had other tables manually added, and the product module has sublevels in the path. PSC00146243 : Client cache viewer tool returns errors ================================================================================ The client cache viewer tool no longer works when run against a current version of the Repository API. PSC00143666 : Copy-Paste in DynView is not keeping all the attributes of the widgets ================================================================================ When copying widgets from a DynView to another DynView, some widget attribute values are missed. For example, when a fill-in is copied, the values of the ShowPopup and Label attributes are missed in the target DynView. This happens for all attributes that are read from the Repository. PSC00140156 : DataFields cut/copied then pasted are associated with RowObject ================================================================================ There is an issue when you cut or copy DataFields from one dynamic viewer and then paste them to another dynamic viewer built from the same SDO. Until you save and reopen the second viewer, the AppBuilder shows the new fields as being associated with the RowObject table instead of their actual database table. PSC00131772 : Toolbar object modifications are not updated in the Toolbar ================================================================================ 011A90108 Toolbar data are cached on the client as soon as they have been read once from the server, so when actions, bands and/or toolbars are changed in the Toolbar and menu designer these changes will not always be reflected in new instances of toolbars. Running the Dynamic Launcher and checking the 'Destroy ADM super-procedures' option will ensure that toolbar data are refreshed. The other option is to restart the session. PSC00128502 : Fields hidden on DynView master layout in design mode if custom layout exists ================================================================================ If a field on a master layout has its HIDDEN attribute set to TRUE, the viewer typically displays the field in design mode. However, if a customized layout is made for the viewer, the viewer does not display the hidden field when the viewer reopens. This is inconsistent with the normal behavior for displaying hidden fields in master layouts. If you need to modify a hidden field in this situation, use the ROM tool. Do not modify the hidden field by using the 'List Objects' button to bring up the property sheet. Doing so removes the field instance. PSC00125407 : scm_checks_on in Security Control is not supported ================================================================================ In Security Control, there is a toggle that switches on and off checks for the use of an SCM tool. The use of this setting is not yet implemented in all the places where it is relevant to check for this setting. SCM functionality is always enabled when the SCM tool (Roundtable) is in use with Progress Dynamics. PSC00247292 : Creating a .zip file on removable media from Visual Translator causes errors ================================================================================ Creating .zip file on removable media from Visual Translator causes the following errors: Error occurred while accessing component property/method: MultiVolumeControl. Out of present range. Error code: 0x8002000a Zip adetran/common/_zipmgr.w (5890) Zip: Couldn't open to write. (15). Note: Creating a .zip file on non-removable storage functions properly. PSC00150235 : Changing the TranMan Language combo may cause error (132) ================================================================================ Changing the selected language on the TranMan Data Tab combo does not display the correct translations after using the 'View', 'Sort' option from the pull down Menu. Double clicking on some rows might give the following error: ** This Translation already exists with Sequence number number Instance Number number Language Name " language ". (132) PSC00181371 : Two undo/reset buttons on the Standardtoolbar ================================================================================ The new UndoChange toolbar action is not supported in Dynamics Web. By default, UndoChange replaces the Reset action in shipped toolbars and Tableio bands. When these toobars and bands are realized in the Web, the Reset button and menu item remain and function correctly. However, the UndoChange action may also be realized at runtime as a non-functioning button and menu item, labeled "Undo 1 (CTRL-Z)". In order to suppress the UndoChange button and menu item, the UndoChange action can be set to Hidden, or added to the HiddenActions property, for the toolbar. For additional information, please see the note for the new UndoChange action under GUIRENDR / SmartToolbar in this document. PSC00144996 : The compileAll option in WebTools has a limitation of URL length of 4096 chars ================================================================================ The compileAll option on AppManager in WebTools has a limitation of URL length being more than 4096 chars, depending of what web browser is being used. Try to limit the size of the compiles, number of files if you run into this problem. PSC00139229 : HTML after WSTag not sent if WSTag runs another WebSpeed object ================================================================================ If a SpeedScript file contains a WSTag tag that runs another WebSpeed object, the remaining HTML after the WSTag tag is not sent to the Web browser. PSC00130586 : WebSpeed detail program called from a WebSpeed report program hangs ================================================================================ A WebSpeed detail program called from a WebSpeed report program might hang when the Add button is used a second time or the Delete button is used. If the detail program is used separately from the report program, the problem does not occur. b. Adapter for SonicESB PSC00240333 : Connnection string limitation for session-managed native ESB Adapter ================================================================================ The combined length of the connection string (composed of a user-id, password, and information fields) must not exceed 30,000 non-Unicode characters when connecting to an AppServer. Exceeding the string length causes an AppServer exception. PSC00220618 : Agents remain locked when ESB Adapter returns a Fault in Sonic Workbench ================================================================================ When using the OpenEdge Adapter for Sonic ESB with a session-free AppServer and persistent procedures, it is important that you release the persistent procedure when your ESB process completes, to prevent having a locked agent. When the adapter returns a fault, you must ensure the Release operation is done in your Fault process. This requires you to keep track of your process ID and have access to it in your Fault process. In the Progress Developer Studio for OpenEdge/Sonic Workbench development environment, Sonic intercepts all fault returns so that it can display the result. Consequently, Fault processes are never run. Setting the Command Parameter ESB Fault Return Mode to "Continue Process with Fault" discards the original message where your Procedure ID is stored, so this is not a viable solution. To free up locked agents on the AppServer, you must restart your development container. Using Persistent Procedures within Sonic ESB processes is discouraged because it greatly complicates the handling of Faults and makes your session-free AppServer operate no differently than a session-managed AppServer. c. AdminServer PSC00323311 : Failure to remove the OpenEdge AdminService from Windows Services during an uninstall ================================================================================ During a 64-bit OpenEdge uninstall, the OpenEdge AdminService will not be removed if the AdminService is stopped. Workaround: Be sure the AdminService is running before you start an OpenEdge 64-bit uninstall. The installer checks the running status of AdminService. If the OpenEdge AdminService is running, the installer stops it, removes it from Windows Services, deletes all registry entries, and then completes the uninstall. PSC00322130 : Admin service fails to start from PROENV ================================================================================ Admin service does not start or work as expected when you install OpenEdge with more than one space in the install (DLC) or Work (WRK) directories. When the Admin service is started from PROENV, it displays the following message: "Could not find or load main class com.progress.chimera.adminserver.AdminServerType". Effected version: All OpenEdge versions d. AppServer PSC00229780 : Startup time of AppServer broker increases when SSL is enabled (Linux and UNIX) ================================================================================ After upgrading to OpenEdge Appserver V11, the AppServer broker's startup time might increase if SSL is enabled. This happens if /dev/random is not populated with random data. The SSL libraries used by the AppServer broker require several kilobytes of random data to properly secure SSL connections to the broker. To resolve the issue, ensure that /dev/random is populated with enough random data. There are two possible solutions: - Move /dev/random to /dev/random_bak, and then add a simlink from /dev/random to /dev/urandom. This makes /dev/random reference /dev/urandom. Note that /dev/urandom is less secure. - Install and run rngd, the random number generator daemon. It increases the entropy pool used /dev/random to provide random data. PSC00244975 : Support for Actional is removed ================================================================================ Support for Progress Actional (including all Actional interceptors for OpenEdge), which was first introduced in OpenEdge 10.2B, is removed from OpenEdge Release 11.1. e. DATASERVER PSC00305085 : Establishing backward compatibility to older server versions ================================================================================ Username/Password encryption feature was implemented in the OE 11.4.0 release for MS SQL Server and Oracle DataServers. With this new feature, users can pass encrypted usernames and passwords to the server. Encryption of credentials have compatibility with versions of the DataServer clients and servers going forward, but a pre-11.4.0 DataServer Server has no support for the encrypted credentials. When a DataServer client tries to connect to an earlier version of the DataServer Server, it fails to decrypt the credentials, and a connection failure results. Version 11.4 of both the MS SQL Server and Oracle DataServers continue to be compatible only with their own 11.4 clients. However in OpenEdge 11.5 release, MSS and Oracle DataServer client has been improved to restore the broken server compatibility which now restricts the server incompatibility to a specific range. Connectivity with encryption in the 11.5 MSS DataServer is now only incompatible with releases between 11.2.x to 11.3.x. Connectivity with encryption in the 11.5 Oracle DataServer is now only incompatible with 11.0.x to 11.3.x releases. On the contrary, the DataServer client will also be capable of making a compatible connection to a comparable DataServer server. For instance, if a MSS DataServer client tries to connect to a release before 11.2.x version, it will result in a successful connection with un-encrypted username/password. However, if a MSS DataServer client tries to connect to a pre-11.4 MSS DataServer Server in the range of 11.2.x and 11.3.x, the MSS DataServer client remains incompatible with these versions. That is, DataServer Server fails to decrypt the credentials and a connection failure results. To establish backward compatibility with older versions in the specified range of incompatible servers, 11.2.x and 11.3.x of the MSS DataServer servers and 11.0.x - 11.3.x of the Oracle DataServer , use the connection-time switch "-znoencrypt". While this switch re-establishes backward compatibility it also disables the encryption feature for that connection. PSC00316718 : Oracle DataServer for coexistence of 32bit OE/64bit OE on 64bit m/c ================================================================================ If a 64-bit oracle client and a 32-bit OpenEdge instance coexists with a 64 bit OpenEdge instance on a Windows 64-bit machine and if the 32-Bit OpenEdge utilizes the Oracle DatServer and configures its Oracle environment to connect to a 64-bit Oracle client library, the user gets the following error message:"Unable to load shared library.(14945) error". If a 32-bit oracle client and a 32-bit OpenEdge instance coexists with a 64 bit OpenEdge instance on a Windows 64-bit machine and if the 64-Bit OpenEdge utilizes the Oracle DatServer and configures its Oracle environment to connect to a 32-bit Oracle client library, the user gets the following error message:"Unable to load shared library.(14945) error". PSC00215517 : Techniques to load .d file when table has non-updatable column on MSSQLServer ================================================================================ In MSS DataServers, there is a restriction to a load operation from a .d file when the table has non-updatable columns (i.e. columns on MS SQL server are of type 'identity' or 'timestamp' or 'rowguid'). You can work-around this restriction by following one of the two options described below. Option 1:- Use dump/load tools of the foreign data source instead of data from a .d file to load your foreign table. Note: This is the only way to retain the original values from non-updatable columns. Option 2:- If the user wants newly generated values for non-updatable columns stored along side updatable fields from the given '.d' file, write an ABL program to read data from the .d file into a temp table and then skip non-updatable fields while writing the temp table records to the foreign table. Sample ABL code provided below to perform this task. Conside a table named "test" on SQL Server side with the sturcture as, TABLE [test]( [fld1] [int] IDENTITY(1,1) NOT NULL, [fld2] [varchar](50) NULL, [fld3] [varchar](50) NULL ) ****** sample ABL code ****** /* define temp table with the name Temptbl for table test */ define temp-table Temptbl like test. /* pouplate temp-table Temptbl from the records in the .d file name test.d */ INPUT FROM test.d. REPEAT: CREATE Temptbl. IMPORT Temptbl. /* create a record in the foreign DB */ CREATE test. BUFFER-COPY Temptbl EXCEPT fld1 TO test. END. INPUT CLOSE. ***************************** PSC00315675 : Establishing ROWID backward compatibility ================================================================================ In the OpenEdge 11.5 release, changes were made to ROWID memory layout area copied into the record buffer for MSS DataServer. With this new enhancement, the ROWID is stripped to be shorter in size. The changes were made to both self-service and progress networking mode of DataServer configuration. The reduced storage size of ROWID in the record buffer now enables MSS DataServer to use reduced network bandwidth for every record transferred using the network. However, if you have generated the ROWID prior to the 11.5 release and are storing it in your database or to some other permanent location and then try to retrieve the stored ROWID using 11.5, the application may fail or display undefined behavior. To establish backward compatibility with pre-11.5 ROWID, use the connection-time switch "-Dsrv PRGRS_ROWID_VER,0" when using dataservers in OpenEdge 11.5 FCS or above. Allowed values for the switch PRGRS_ROWID_VER are 0 and 1 with default set to 1. This switch re-establishes backward compatibility with the stored ROWID generated with older releases by retaining the old format for ROWID. Additionally, the existing connection switch -Dsrv ZPRGRS_RECID_BUF_SIZE has been modified to accept a RECID buffer size value as low as 13 starting in OpenEdge 11.5 when PRGRS_ROWID_VER is set to 1. In previous versions of OpenEdge and when the PRGRS_ROWID_VER is set to 0 in OpenEdge 11.5 or higher, the minimum size for the -Dsrv switch ZPRGRS_RECID_BUF_SIZE continues to be 52. To set an optimal size for ZPRGRS_RECID_BUF_SIZE for a particular schema image from MS SQL Server, it is recommended that you execute the following script while connected to the MSS logical database of your schema holder. /****************************************************/ DEFINE VAR tot_recid_buf_siz AS INT INIT 0. DEFINE VAR min_recid_buf_siz AS INT INIT 0. DEFINE VAR headr_siz AS INT INIT 9. DEFINE VAR ofst AS INT INIT 2. /* 2 byte offset */ DEFINE VAR unknw AS INT INIT 1. /* 1 byte for UNKNOWN */ DEFINE VAR surrogate_key_size AS INT INIT 8. DEFINE VAR largest_rowid_index AS CHARACTER. DEFINE VAR filname AS CHARACTER. DEFINE VARIABLE prgsrowidunq AS LOGICAL INIT NO. DEFINE VAR numcomp AS INT. /* variables for frame */ DEFINE VARIABLE min_recid_siz AS CHARACTER LABEL "RECID_SIZE" NO-UNDO. DEFINE VARIABLE logicaldb AS CHARACTER LABEL "Logical Db" NO-UNDO. DEFINE VARIABLE rowi_index AS CHARACTER LABEL "LargestROWIDIndex" NO-UNDO. DEFINE VARIABLE tabname AS CHARACTER LABEL "TABLE" NO-UNDO. DEFINE VARIABLE hasprgsrecidunq AS LOGICAL LABEL "PROGRESS RECID UNQIUE" NO-UNDO. DEFINE FRAME buf-size min_recid_siz AT ROW 1 COLUMN 1 logicaldb AT ROW 1 COLUMN 20 rowi_index AT ROW 1 COLUMN 34 tabname AT ROW 1 COLUMN 60 hasprgsrecidunq AT ROW 1 COLUMN 80 WITH SIZE 100 by 100 TITLE "-Dsrv ZPRGRS_RECID_BUF_SIZE parameter can be set no smaller than:" USE-TEXT. FOR EACH _db WHERE _db-type = 'MSS' WITH FRAME buf-size: FOR EACH _file OF _db WHERE _hidden = NO: IF _fil-misc1[1] 0 THEN DO: /* PROGRESS_RECID */ numcomp = 1. tot_recid_buf_siz = headr_siz + (numcomp + 1) * ofst + surrogate_key_size. IF tot_recid_buf_siz min_recid_buf_siz THEN DO: min_recid_buf_siz = tot_recid_buf_siz. largest_rowid_index = "PROGRESS_RECID". filname = _file-name. END. END. ELSE DO: /* Other than PROGRESS_RECID */ FOR EACH _index OF _file WHERE _idx-num = _fil-misc1[2]: ASSIGN numcomp = _num-comp. IF INDEX(_I-misc2[1],"v") 0 THEN DO: ASSIGN numcomp = _num-comp + 1 /*PROGRESS_RECID_UNIQUE */ tot_recid_buf_siz = tot_recid_buf_siz + surrogate_key_size. END. ASSIGN tot_recid_buf_siz = headr_siz + numcomp * unknw + (numcomp + 1) * ofst. FOR EACH _index-field OF _index: FIND _field WHERE RECID (_field) = _index-field._field-recid. tot_recid_buf_siz = tot_recid_buf_siz + _fld-misc1[3]. END. IF tot_recid_buf_siz min_recid_buf_siz THEN DO: min_recid_buf_siz = tot_recid_buf_siz. largest_rowid_index = _index-name. filname = _file-name. IF INDEX(_I-misc2[1],"v") 0 THEN prgsrowidunq = YES. END. END. END. END. DISP STRING (min_recid_buf_siz) AT ROW 1 COLUMN 11 _db._db-name AT ROW 1 COLUMN 20 NO-LABEL largest_rowid_index FORMAT "x(30)" AT ROW 1 COLUMN 34 NO-LABEL filname FORMAT "x(20)" AT ROW 1 COLUMN 60 NO-LABEL prgsrowidunq AT ROW 1 COLUMN 80 NO-LABEL. END. /****************************************************/ PSC00246724 : R-code compiled in OpenEdge 11 before and after this fix must be recompiled ================================================================================ 32-bit and 64-bit datasever r-code compiled in OpenEdge 11.2.0 is incompatible with OE 11 releases before and after it due to a change of data stored in r-code. Corrections are required for all r-code compiled against the DataServer for MS SQL Server in releases other than 11.2.0. Release 11.2.0 r-code is only compatible with its own run-time. Moving Release 11.2.0 MSS DataServer r-code to later releases (11.2.1+ or 11.3+) requires a recompile even if you recompiled once already in moving to 11.2.0. PSC00246559 : Recompile r-code in 11.2.1/11.3.0 from OpenEdge 11.2 or previous V11 versions ================================================================================ 32-bit and 64-bit platform r-code compiled on OpenEdge 11.2 (or previous versions) must be recompiled at least once before being executed on OpenEdge 11.2.1 or later versions. Corrections were required for all r-code compiled against the DataServer for MS SQL Server due to 64-bit alignment issues associated with stored r-code that affect run-time capabilities on both 32 and 64 bit platforms. PSC00242399 : Existing MSS logical schema requires an update to enable certain LOB operations ================================================================================ In MS SQL DataServer, partial LOB operations with non-native MS SQL Server drivers had resulted in an error. The schema