Developer Documentation
PATH  WebObjects 4.0 Documentation > EOF Release Notes

Enterprise Objects Framework 3.0 Release Notes

Last Updated October 22, 1998

This document lists those problems known to exist in this release of Enterprise Objects Framework, and suggests ways to avoid or work around these problems. Please refer to the bug reference number if you need to contact Apple about a bug's status.

Release notes for WebObjects, if it is installed,are listed separately and can be found here.

Among the documention supplied with this release is "What's New in Enterprise Objects Framework 3.0", which details those features that are new or have substantially changed since the last release of Enterprise Objects Framework.



Obtaining and Installing Database Client Libraries on Windows NT

To use Enterprise Objects Framework on Windows NT, you must have the appropriate database client libraries. The Sybase client libraries are provided on the WebObjects Developer 4.0 CD as an optional package. To install the Sybase client libraries, you must do a custom installation and explicitly specify that you want to install the package. To use Enterprise Objects Framework with Oracle or Informix, you must purchase the appropriate client libraries from your database vendor.

Oracle

Phone: (800) 542-1170 or call your local sales representative

Ask for: Oracle 8 Client

The Oracle adaptor on NT requires the Oracle 8.0, 7.3, or 7.2 Client Library. It won't work with the 7.1 libraries.

On Windows NT, using the latest release of the Oracle client library (8.0) requires you to use SQL*Net v2, which requires a tnsnames.ora file. tnsnames.ora is a file that you put on client machines, generally in the directory Orant/Network/Admin or Orant/Net80/Admin. The file contains information needed to connect to a server over the network. Entries in tnsnames.ora are keyed off of a server ID alias, and they include information such as the server ID, the host machine name, and the network protocol used by the client library to resolve the server ID alias. An entry in tnsnames.ora might resemble the following:

myServerAlias = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=myMachine) (PORT=1521))(CONNECT_DATA=(SID=eof)))

Oracle provides tools you can use to create tnsnames.ora files. Refer to your Oracle documentation for more information on tnsnames.ora files and the tools you can use to create them.

If you're using the 7.2 version of the Oracle client libraries on Windows NT, you can use either SQL*Net v1 or SQL*Net v2. To use SQL*Net v1, you should set your adaptor's connectionDictionary serverId entry to

T:<host-machine>:<server-name>

Informix

Phone: (800) 331-1763 or call your local sales representative

Ask for: ESQL/C version 7.23.TC9 for Win32

If you get the error "INFORMIXSERVER not in sqlhosts file (25596)" but can connect to your database server using the Informix ilogin program, you may need to run SetNet32 to update the environment variables used by Informix.

The Informix client libraries appear to have redundant sources of server information. They use the sqlhosts file ($INFORMIXDIR/etc/sqlhosts) as well as a collection of environment variables managed by the Setnet32 program.

See your Informix documentation for more information on the sqlhosts file and the Setnet32 program.

Sybase

Phone: (800) 685-8225 or call your local sales representative

Ask for: OpenClient/C Version 11.1



Obtaining and Installing Database Client Libraries on Solaris

To use Enterprise Objects Framework on Solaris, you must have the appropriate database client libraries.

Here's what you need:

Oracle

Phone: (800) 542-1170 or call your local sales representative

Ask for: 8.0 SQLNet V2 TCP/IP Client libraries

The Oracle adaptor on Solaris requires the Oracle 8.0 or 7.3 Client Library. The makefiles are configured for 7.3 or 8.0 (they default to 7.3); with some modifications of the makefiles, you can also link with 7.2.

Informix

Phone: (800) 331-1763 or call your local sales representative

Ask for: ESQL/C Version 7.23.UC9

If you get the error "INFORMIXSERVER not in sqlhosts file (25596)" but can connect to your database server using the Informix ilogin program, you may need to run SetNet32 to update the environment variables used by Informix.

The Informix client libraries appear to have redundant sources of server information. They use the sqlhosts file ($INFORMIXDIR/etc/sqlhosts) as well as a collection of environment variables managed by the Setnet32 program.

See your Informix documentation for more information on the sqlhosts file and the Setnet32 program.

Sybase

Phone: (800) 685-8225 or call your local sales representative

Ask for: OpenClient/C Version 11.1

Linking Against the Adaptor

On Solaris applications must explicitly link against the adaptor framework and the client libraries. New makefiles look for adaptor frameworks and automatically add in the right linker arguments. Simply add the adaptor framework to your project, and set the requisite environment variable specifying where the client libraries are installed. For Oracle set ORACLE_HOME and optionally ORACLE_REL. (The ORACLE_REL flag controls which set of libraries are used. It uses the Oracle 7.3 static link libraries by default, but you can also specify "8.0-static" or "7.3-dynamic".) For Sybase set SYBASE_HOME. For Informix set INFORMIX_HOME.

If you use dynamic libraries on Solaris, you need to set the LD_LIBRARY_PATH environment variable when running your application.



Obtaining and Installing Database Client Libraries on HP-UX

To use Enterprise Objects Framework on HP-UX, you must have the appropriate database client libraries.

Oracle

Phone: (800) 542-1170 or call your local sales representative

Ask for: 8.0 SQLNet V2 TCP/IP Client libraries

The Oracle adaptor on HP-UX requires the Oracle 8.0 or 7.3 Client Library. The makefiles are configured for 7.3 or 8.0 (they default to 7.3); with some modifications of the makefiles, you can also link with 7.2.

Informix

Phone: (800) 331-1763 or call your local sales representative

Ask for: ESQL/C Version 7.23.UC6

If you get the error "INFORMIXSERVER not in sqlhosts file (25596)" but can connect to your database server using the Informix ilogin program, you may need to run SetNet32 to update the environment variables used by Informix.

The Informix client libraries appear to have redundant sources of server information. They use the sqlhosts file ($INFORMIXDIR/etc/sqlhosts) as well as a collection of environment variables managed by the Setnet32 program.

See your Informix documentation for more information on the sqlhosts file and the Setnet32 program.

Sybase

Phone: (800) 685-8225 or call your local sales representative

Ask for: OpenClient/C Version 11.1

Linking Against the Adaptor

On HP-UX applications must explicitly link against the adaptor framework and the client libraries. New makefiles look for adaptor frameworks and automatically add in the right linker arguments. Simply add the adaptor framework to your project, and set the requisite environment variable specifying where the client libraries are installed. For Oracle set ORACLE_HOME and optionally ORACLE_REL. (The ORACLE_REL flag controls which set of libraries are used. It uses the Oracle 7.3 static link libraries by default, but you can also specify "8.0-static" or "7.3-dynamic".) For Sybase set SYBASE_HOME. For Informix set INFORMIX_HOME.



Known Problems in This Release


Enterprise Objects Framework
Reference2278245
Problem Raw row fetches cannot use object-based qualifiers
Description When a fetch specification is set to fetch raw rows (dictionaries), as opposed to full Enterprise Objects (see setFetchesRawRows:), the qualifier may not use object-based qualifiers. The code that implements the raw row fetching incorrectly transforms object-based relationship qualifiers into foreign key qualifiers.
Workaround     Fetch full EOs when the qualifier has references to relationships. Use raw row fetching only with a qualifier based directly on the attributes of the entity.
  
Reference2182008
Problem An NSNumber primary key with a value of 0 is assumed to mean NULL, invoking EOF's primary key generation (perhaps erroneously).
Description Starting in EOF 2.2, EODatabaseContext assumes that an object with a single attribute primary key with a value of zero indicates a newly created instance. And as such, EOF attempts to get a new primary key for the object using the delegate hook or the adaptor-specific primary key generation mechanism. This change allows you to use scalar data types in your EO's (like "int") for primary keys, and still rely on EOF's automatic primary key generation. Unfortunately, if you have an existing database rows with primary keys of 0, attempts to update corresponding enterprise objects cause the EODatabaseContext to incorrectly attempt to get a new primary key. This can leave invalid foreign key refernces in other tables.
Workaround     Implement the EODatabaseContext delegate method databaseContext:newPrimaryKeyForObject:entity: and catch the case where the framework will mistakenly get a new key.

From EODatabaseContext.h
- (NSDictionary *)databaseContext:(EODatabaseContext *)context
newPrimaryKeyForObject:(id)object
entity:(EOEntity *)entity;
// If a newly inserted EO doesn't already have have a primary key set,
// this delegate is called to generate a key. If the delegate is not implemented,
// or returns nil, then the DatabaseContext will call
// [EOAdaptorChannel primaryKeyForNewRowWithEntity:(EOEntity *)entity]
// to attempt to generate the key.

Example delegate implementation:
{
...
model = [[EOModelGroup defaultGroup] modelNamed:@"myModel"];
dbContext = [EODatabaseContext registeredDatabaseContextForModel:model editingContext:editingContext];
[dbContext setDelegate:self];
...
}

- (NSDictionary *)databaseContext:(EODatabaseContext *)context
newPrimaryKeyForObject:(id)object
entity:(EOEntity *)entity
{
if (entity == entityThatIKnowHasAValidRowWithAKeyOfZero)
Eif ([[object valueForKey:primaryKeyThatCanBeZero] isEqual:[NSNumber zero]])
return [NSNumber zero];
return nil;
}
  
Reference2177721
Problem You can't update rows containing string attributes with trailing spaces.
Description The EOF adaptors automatically strip trailing spaces from string values fetched from the database. They also strip spaces on newly inserted strings before sending them to the database. This works fine until you fetch data that a non-EOF app inserted that contains trailing spaces. If that attribute is used for locking, then EOF is unable to update the row (because it the version in the database is different than the space-stripped version in the snapshot).
Workaround     Do not mark columns that could contain trailing spaces as used for locking. Alternately, strip the spaces from the data in your server.
  
Reference2169039
Problem Alert panel displaying adaptor error is never dismissed.
Description This occurs whenever an adaptor operation that was invoked from an awakeFromNib: method displays an alert panel. The problem is that the entire object graph is not yet instantiated when awakeFromNib: is invoked.
Workaround     Database operations should be begun from the applicationDidFinishLaunching: method rather than the awakeFromNib: method. Of course, this means that any methods that indirectly cause database communication should also be invoked from the applicationDidFinishLaunching: method.
  
Reference2165078
Problem Seemingly innocuous qualified fetch always causes exception.
Description Some qualified fetches raise exceptions because values in the SQL have been formatted as strings when they should have been formatted as some other type. This can happen when you enter an invalid external type or when a Sybase model doesn't contain information about user-defined types that are used in the model.
Workaround     In the case of an invalid external type, simply correct it. In the case of a user defined type, create a new model by reverse engineering the database. The new model's connection dictionary contains information about user-defined types. Copy the connection dictionary from the new model to the original one.
  
Reference2147832
Problem Enterprise Objects Framework can't update attributes whose internal types are custom (such as NSImages).
Description A custom value class must implement isEqual: to be used for attributes marked as used for locking.
Workaround     Implement isEqual: in the custom value class or don't mark the attribute as used for locking.
  
Reference2172619
Problem EOAdaptorChannel does not inherit EOAdaptor's delegate.
Description According to the EOAdaptorChannel class specification and header file, the EOAdaptorChannel's delegate should automatically be kept in synch with its adaptor. Indeed, if a new delegate is assigned to an EOAdaptor, the new delegate is propagated to any of that adaptor's existing contexts and channels. However, if you create an EOAdaptor, assign a delegate to it, and then create EOAdaptorContexts and EOAdaptorChannels, the newly-created contexts and channels don't have the delegate assigned to them.
Workaround     Wait until all of the channels and contexts are instantiated before assigning the adaptor's delegate, or reassign the adaptor's delegate each time a new channel or context is created.
  
Reference2275676
Problem On HP-UX, you cannot link an application that uses more than one EOF adaptor
Description On HP-UX, each adaptor defines the _EOInitEnviron and _EOSetEnviron symbols. Because of this, if you try to link an application with more than one adaptor you'll get multiply defined symbols.
Workaround     None.
  
Reference2203426
Problem EOF adaptors reject wildcard search strings that are wider than the width of the corresponding attribute
Description For literal strings, the EOF adaptors correctly reject strings that are too wide for the attribute. However, when doing wildcard searches using LIKE, EOF incorrectly rejects some strings containing wildcards which should be legal but happen to have more characters than the attribute's width. For example, a pattern like "*A*B*" is perfectly reasonable for matching against a three character column, but EOF will raise an error saying that the search string exceeds the width of the three character attribute.
Workaround     In many cases, the wildcard search string can fit within the attribute's width and there is no problem. In other cases, the attribute can be given a larger width in the model so that a desired wildcard search string will fit. If you employ the latter solution, be sure to reset the attribute's width to the correct value before using the model to generate database tables.
  
Reference2176885
Problem The set of valid values for the databaseEncoding entry of a connection dictionary are not documented, and the set can vary in different locales.
Description A connection dictionary's databaseEncoding entry contains the localized name for the string encoding. The localized names are not documented. Furthermore, the localized names for string encodings can vary with the user's locale. Consequently, the specified encoding for an application might not work for users in different locales.
Workaround     You can find the localized name for string encodings in /Library/Frameworks/Foundation.framework/Resources/<language>.lproj/EncodingNames.strings.
  
Reference2163118
Problem Schema generation may produce identifiers that are too long.
Description If your database table names are long, the names generated for constraints may be too long.
Workaround     Shorten your table names, or edit the SQL EOModeler generates to shorten the constraint names.
  
Reference2177354
Problem There are problems saving changes to attributes with mutable custom value objects.
Description Suppose you have a mutable custom value type, PhoneNumber, that implements mutator methods like setAreaCode:, setPrefix:, and so on. If you modify one of these values and save changes, the enterprise object is not saved to the database.
Workaround     To use mutable value classes you must do three things:

1) In the PhoneNumber value class object, implement isEqual: to appropriately compare two instances.

2) If the PhoneNumber value is modified, it's owning enterprise object must (first) invoke [self willChange];

3) The enterprise object must provide a set method that copies rather than retains the object passed to it:

- (void)setDayTimePhone:(PhoneNumber *)number {
[dayTimePhone autorelease];
dayTimePhone = [number copy];
}

#1 would be required, even in a perfect world. #2 is a requirement of the basic EOF architecture. #3 is required because of a bug -- EOF should pass enterprise objects a copy of their values (currently we are passing the the same instance that's shared in the snapshot).

In general, your simplest workaround is to use immutable custom value objects.
  
Reference2176526
Problem Applying a qualifier with key path to top of horizontally mapped inheritance hierarchy generates invalid SQL.
Description Enterprise Objects Framework's query building mechanism doesn't handle relationships to inheritance hierarchies. For example, suppose that you are are attempting to qualify a fetch through a to-many relationship (planes) that points to the top of a horizontally mapped inheritance hierarchy (for the entities Plane, FighterPlane, and TrainerPlane). If you want the query to test against all tables, you'd expect Enterprise Objects Framework to generate SQL similar to the following:

SELECT t0.AIRPORT_ID
FROM PLANE t1, FIGHTER t2, TRAINER t3, AIRPORT t0
WHERE
(t1.LENGTH <= 1000 AND t0.AIRPORT_ID = t1.AIRPORT_FK) OR
(t2.LENGTH <= 1000 AND t0.AIRPORT_ID = t1.AIRPORT_FK) OR
(t3.LENGTH <= 1000 AND t0.AIRPORT_ID = t1.AIRPORT_FK)

Instead, Enterprise Objects Framework generates the following SQL:

SELECT t0.AIRPORT_ID
FROM PLANE t1, AIRPORT t0
WHERE
(t1.LENGTH <= 1000) AND
t0.AIRPORT_ID = t1.AIRPORT_FK

In other words, only the table for the root of the hierarchy is queried.
Workaround     You can create a qualifier that generates the correct SQL by:

1. Adding relationships in the source entity to all the tables in the inheritance hierarchy. For example, to the Airport entity, you'd add the relationships toFighters and toTrainers to the destination entities FighterPlane and TrainerPlane, respectively. Mark the relationships so they aren't class properties.

2. When building your query, explicitly list these extra relationships. In the Planes example, you'd fetch from Airport where "planes.length < 1000 OR toFigtherPlanes.length < 1000 OR toTrainerPlanes.length < 1000"

Alternatively, you might be able to solve this problem more generally by writing a post processor for EOQualifiers that splits up clauses that perform inheritance tests. The post processor could even programmatically generate the additional relationships on demand and register them with the model using names like "plane_Subclass_Fighter".

A generic EOQualifier post processor could be wired into Enterprise Objects Framework so that application writers don't have to know it exists. The right place for such a mechanism is probably in EOKeyValueQualifier's schemaBasedQualifierWithRootEntity: method (see EOSQLQualifier.h). You could put the post processor code in a subclass of EOKeyValueQualifier (with an appropriate call to super after the transformation, if any, is performed) and have your subclass pose as EOKeyValueQualifier.
  
Reference2174379
Problem EODatabaseContext can't be the direct parentObjectStore of an EOEditingContext.
Description The EODatabaseContext requires that an EOObjectStoreCoordinator sit between it and any EOEditingContexts that it serves. This is the default configuration set up by the framework, so you shouldn't normally run into this problem. Just a reminder, you can set up an editingContext and be ready to go with this one line:

EOEditingContext *editingContext = [EOEditingContext new];
// automatically uses [EOObjectStoreCoordinator defaultCoordinator]
// as parentObjectStore

Any necessary EODatabaseContexts are created and registered automatically.
Workaround     Don't assign an EODatabaseContext as the parentObjectStore of an EOEditingContext. There's no benefit to doing so anyway.
  
Reference2174345
Problem You can't update to-many relationship if the foreign key isn't marked as a class property or as used for locking.
Description Suppose that an entity's foreign key attribute isn't marked as a class property or as used for locking. If you designate the foreign key attribute as a to-many relationship's destination key, the foreign key value isn't always updated. This occurs because the destination entity doesn't know that the attribute participates in a relationship. Therefore, the destination entity doesn't fetch the foreign key from the database or update it.
Workaround     Mark attributes that are destination keys of a to-many relationship so they are fetched. For example, you could:
- Mark them as class properties.
- Mark them as used for locking.
- Use them in inverse relationships to the problematic to-many's source entity.
  
Reference2169671
Problem EODatabase never releases snapshots
Description When you fetch information from the database in an EOF application, a snapshot of that information is created and stored in memory. These snapshots are never automatically released from memory. Even when the EOEditingContext which fetched and created the snapshot is deallocated, the snapshot persists.
Workaround     If you just want to periodically garbage collect, keep a list of your editing contexts (you could have a subclass of EOEditingContext that registered itself in a non-retaining global array -- perhaps in the userInfo of the EOObjectStoreCoordinator) and then periodically traverse the contexts to build an NSSet of used snapshots (use [ec registeredObjects] in
combination with [EOFault isFault:] and [ec globalIDForObject:]). Now that you have the set, walk through the EODatabase instances and get the list of all globalIDs (call [[db snapshots] allKeys] to get the list). Subtract the sets to get the list of snapshots to be invalidated, and call
[objectStoreCoordinator invalidateObjectsWithGlobalIDs:]). This procedure could be encapsulated in a category method on EOObjectStoreCoordinator.
  
Reference2161475
Problem Enterprise Objects Framework performs less efficient deep fetches for single-table inheritance mappings than it should.
Description To perform a deep fetch, Enterprise Objects Framework performs a fetch for each concrete class in an inheritance hierarchy. For a single-table inheritance mapping, Enterprise Objects Framework should perform only one fetch and then sort the results in memory. For example, if Person, Employee, and Customer objects are stored in one table?the PERSON table?the Framework should perform one fetch on the PERSON table to fulfill a deep fetch request of Person, Employee, and Customer objects. Instead, it performs three fetches: one to get Person objects, one to get Employee objects, and another to get Customer objects.
Workaround     Define only one entity for the entire inheritance hierarchy, and use the EOModelGroup delegate methods subEntityForEntity:primaryKey:isFinal:, and entity:classForObjectWithGlobalID: to create instances of the proper subclasses from database rows.
  
Reference2174251
Problem Changes made during saveChanges are silently lost.
Description If you change an enterprise object while its editing context is in it's saveChanges method (for example, if you change an enterprise object in an EODatabaseContext delegate method), the changes may be silently lost.
Workaround     Don't make changes to objects during the save process. Instead, make the changes from the EOEditingContext delegate method editingContextWillSaveChanges:.
  
Reference2164084
Problem Inserted enterprise objects don't get removed from EODisplayGroup after sending revert to EOEditingContext.
Description If you fetch objects into an EODisplayGroup, insert a few objects, delete a few objects, and then update a few objects; telling the EOEditingContext to revert backs out the updates, but not insertions or deletions. The actual insertions and deletions have been reverted, but the EODisplayGroup doesn't know how to revert its object list (since is doesn't keep track of what its original object list was before the insertions and deletions).
Workaround     Programmatically tell all affected EODisplayGroups to refetch after telling the EOEditingContext to revert, or use refetch: (invalidateAllObjects:) instead of revert.
  
Reference2176892
Problem Multiple fetch-on-load display groups associated with an invalid connection dictionary can cause an exception.
Description When loading a nib file that has more than one display group set to fetch on load, an application can crash if the display groups' model has an invalid connection dictionary. A crash occurs because the second display group tries to run the adaptor's login panel while the first one already has the panel open. This confuses the Application Kit.
Workaround     Validate the connection dictionaries for all models in the [EOModelGroup defaultGroup] before opening the nib.
  
Reference2176152
Problem Inserting and deleting objects involved in inverse, to-many relationships can be very slow.
Description Suppose that a ServiceRequest has a to-one relationship to its CustomerServiceRepresentative, and that the CustomerServiceRepresentative has an inverse to-many relationship to its ServiceRequests. When you assign a request to a representative using addObject:toBothSidesOfRelationshipWithKey:, you fire the fault for the CustomerServiceRepresentative.serviceRequests. So, if a representative has a large number of requests, assigning a new request to a representative can be very slow. Correspondingly, when you delete a request, Enterprise Objects Framework fires the corresponding representative's serviceRequests fault so it can remove the request from the array.
Workaround     Set the inverse, to-many relationship so it isn't a class property. For example, in the above request-represpentative scenario, you would remove the serviceRequests relationship from the class properties of the CustomerServerRepresentative entity.
  
Reference2280851
Problem EOF has facilities to aid in debugging multithreaded problems
Description Some classes in EOF (notably EOEditingContext and EODatabaseContext) can check to see whether they are being accessed in a thread-safe manner. To turn on these facilities, activate the user default EOLockingDebugEnabled. For example, run your program with the command line argument -EOLockingDebugEnabled YES. You can then set a breakpoint on _EOBadMultithreadedAccess to see where the unprotected access is occuring.
Workaround     None.
  
Reference2272980
Problem The EODisableClassParser user default isn't documented
Description In EOF 3.0, InterfaceBuilder is integrated with a class parser that will automatically read keys from your source code. Because this may negatively affect performance when you are editing a nib file, there is a user default to turn off the class parsing. In order to turn off the class parsing, type the following on the command line:

"defaults write InterfaceBuilder EODisableClassParser YES"
Workaround     See the description, above.
  
Reference2266541
Problem The EOProjectSourceSearchPaths user default is now NSProjectSearchPath
Description EOProjectSourceSearchPaths is deprecated. Use NSProjectSearchPath instead. However, for backwards compatibility, EOProjectSourceSearchPaths will be used if there is no default value for NSProjectSearchPath.

NSProjectSearchPath is an optional array of paths which should contain project source directories. At development time (in InterfaceBuilder and EOModeler) EOF searches this patch for models in frameworks used by the application being edited.
Workaround     Use NSProjectSearchPath.
  
Reference2266127
Problem EOFDebugUndo is obsolete
Description The EOFDebugUndo user default is obsolete due to the fact that EOUndoManager changed into NSUndoManager.
Workaround     None.
  
Reference2264062
Problem The Java versions of the adaptor classes are documented as "abstract," but they aren't so implemented
Description The Java version of the adaptor class reference documentation is slighly out of sync with the implementation. There is no reason to create an instance of any of these classes. Use EOAdaptor.adaptorWithName() to create your adaptors.
Workaround     Ignore the "abstract" keyword in the Java adaptor class reference documentation.
  
Reference2246743
Problem The OpenBase Lite LIKE operator is always case-insensitive.
Description There is no way to perform a case sensitive LIKE comparison with the OpenBase Lite database.
Workaround     There is no convenient workaround. Depending on the application, = may be sufficient, or the programmer may have to do a case-sensitive comparison in memory using a custom comparison method.
  
Reference2273015
Problem SetupWizard: primary key generation may not work when installing into a Sybase database
Description If you run the SetupWizard and install both the Movies and Rentals databases into the same Sybase database, the automatic primary key generation will not work for the Movies schema.
Workaround     Open the Movies eomodel in EOModeler and use Generate SQL to generate primary key support ONLY. Ignore any warnings you may get from the database.
  
Reference2260833
Problem EOAttribute has "Value Class" and "Value Class Obj-C" columns; these are really the same thing.
Description The "Value Class" column is old. It is included only to prevent problems for users with defaults information from a previous version of EOModeler.
Workaround     Only use one of the columns.
  
Reference2275174
Problem Cannot delete an EOFetchSpecification in EOModeler: the "Cut" and "Delete" menu items are not enabled
Description It is possible to get a fetch specification that incorrectly disables the "Cut" and "Delete" menu items. This usually happens when you have a new fetch specification without a name.
Workaround     Use the "Cut" icon on the toolbar, or give the EOFetchSpecification a new or different name.
  
Reference2177608
Problem Existing EOF projects don't see the new EOF 3.0 source-code generation templates
Description Enterprise Objects Framework 3.0 includes fixes and additions to EOInterfaceFile.template and EOImplementationFile.template. If you have an EOF 2.x project that contains the old versions of these files, the old versions will continue to be used when you generate source files in EOModeler.
Workaround     If you haven't customized the templates, just remove EOInterfaceFile.template and EOImplementationFile.template from your project. EOModeler will then use the most up-to-date versions of these files.

If you want to build a customized template based on the newest versions, copy /Developer/Applications/EOModeler.app/Resources/EOImplementationFile.template and /Developer/Apps/EOModeler.app/Resources/EOInterfaceFile.template into your project directory.
  
Reference2177631
Problem An EORelationship can return nil for its inverseRelationship after the inverse is added
Description The first time you ask the EORelationship for its inverseRelationship it searches all relationships in its destinationEntity looking for an inverse, it caches the result of this search. This cache does not always get invalidated when the relationships of the destinationEntity change, so after editing a model and adding an inverse relationship to an EORelationship (either in code or with EOModeler), an inverseRelationship message sent to the EORelationship can return nil.
Workaround     See the category on EORelationship in the ModelerBundle/RelationshipExtras.m example.
  
Reference2159472
Problem Derived attributes are limited and don't offer full SQL as advertised.
Description Placing a string or a numeric constant in the definition field of a derived attribute generates invalid SQL. Definitions such as "title" and "0.0" don't work correctly. However, definitions such as "att1 + 5" should work correctly when "att1" specifies another attribute.
Workaround     None.
  
Reference2176256
Problem Additions or changes to a relationship in a parent entity aren't pushed down the children
Description AnyAny additions or changes you make using EOModeler to a relationship in a parent entity won't get pushed down to the parent's children. Changes to attributes are propagated correctly, but relationship information is lost. This can make editing parent EO's rather tedious and error prone
Workaround     Use at least two windows onto the same model, allowing you to see the parent and its children at the same time. This should make it easier to catch changes that don't get progagated.
  
Reference2275826
Problem EOPalette won't parse keys from the source code of client-side Java classes
Description If you drop a display group into a client-side nib, EOPalette won't recognize keys from the client-side class associated with the entity. Instead, it parses keys from the server side class.
Workaround     Add any keys you need manually, using the EODisplayGroup inspector.
  
Reference2174947
Problem Interface Builder crashes after adding a symbolic link for a model to a project
Description On MacOS X Server, if you drag a symbolic link for a model into Interface Builder and answer YES to the "add Model to project" panel, Interface Builder crashes.
Workaround     Drag the actual model file instead of the symbolic link.
  
Reference2157842
Problem EODisplayGroup sometimes doesn't show its keys in Interface Builder's Inspector
Description When Enterprise Objects Framework is unable to find the model file for an EODisplayGroup's entity, Interface Builder's Inspector won't show the EODisplayGroup's keys. To verify that this is the problem, inspect the EODisplayGroup's data source (click on the EODisplayGroup, open the Inspector panel, and select the DataSource panel from the Inspector popup). If the Model field is blank, Enterprise Objects Framework is unable to find your model.
Workaround     Quit Interface Builder and verify that the model containing the entity referenced in the EODisplayGroup is added as a resource in the project containing the nib file.
  

OpenBase Lite
Reference2282377
Problem OpenBase Lite changes the current working directory
Description When OpenBase Lite connects to a database, it changes the current working directory to the database directory. If your code expects the current working directory to remain the same as it was when the application was launched, it may not work correctly.
Workaround     Your code should use absolute pathnames, and should not depend on the current working directory. Command-line arguments for filenames should also be absolute pathnames.
  
Reference2276780
Problem OpenBase Lite logs a spurious error message if EO_PK_TABLE doesn't exist
Description The obliteadaptor generates primary keys from an EO_PK_TABLE. The adaptor knows how to create the table if it doesn't exist. However, the OpenBaseLiteAPI.framework still writes a log message: "SQL ERROR - [position 26, near 'WHERE'] (1) table 'EO_PK_TABLE' does not exist." This can safely be ignored.
Workaround     None necessary, just ignore the spurious error message.
  
Reference2275255
Problem OpenBase Lite cannot be used for deployment
Description OpenBase Lite is an unsupported development database and is not licensed for use in deploying WebObjects applications and websites. Multi-user versions of OpenBase can be purchased to support WebObjects deployment.
Workaround     For information on OpenBase deployment licenses contact OpenBase International, Ltd. at 1-603-547-8404 or visit their web site at http://www.openbase.com.
  

Oracle Adaptor
Reference2177990
Problem The primary-key-support creation code can die, causing subsequent database installation procedures to fail.
Description Sometimes when you run the install_database script or use the schema object creation window in EOModeler, one of the following errors may occur:

Mar 27 10:19:34 eoutil[1577] Exception running dump: ORA-00955: name is already used by an existing object
create table !!! eo_temp_table as select max(MOVIE_ID) counter from MOVIE

OR

Mar 27 10:27:54 eoutil[1591] Exception running dump: ORA-00955: name is already used by an existing object
create procedure !!! eo_set_sequence is
xxx number;
yyy number;
begin
select max(counter) into xxx from eo_temp_table;
if xxx is not NULL then
yyy := 0;
while (yyy < xxx) loop
select MOVIE_SEQ.nextval into yyy from dual;
end loop;
end if;
end;

The reason for these errors is as follows. If the primary-key-support code dies unexpectedly, it can leave the eo_set_sequence stored procedure and the eo_temp_table table in the user's schema. This isn't a problem right away, but any subsequent attempt to run the install_database script will fail because the statements that attempt to create these schema objects will fail, and the data loading will stop before it is finished.
Workaround     Use the following commands from SQLPlus to remove these objects before you attempt to create the schema objects with the install_database script:

SQL> drop table eo_temp_table;
SQL> drop procedure eo_set_sequence;
  
Reference2177517
Problem Updating LONG ROW columns in Oracle with lockingOnDemand causes an exception.
Description Using lockingOnDemand on Oracle, when you try to update an enterprise object with an attribute that maps to a LONG RAW columm, the following exception is raised:

"fetchObject -- EODatabaseChannel 0x12345678: attempt to lock object that has out of date snapshot".

This is because the Oracle Database sometimes returns incorrect BLOB values when the Framework sends "SELECT ... <long-raw-column,... FOR UPDATE". So when the EODatabaseChannel attempts to acquire a lock on the row, the results of the SELECT don't match the results we got on the last SELECT (without the FOR UPDATE clause).

Workaround: You cannot use the lockingOnDemand mode of locking if you are going to be updating tables with LONG RAW columns that are marked used for locking in the model. Mark the long columns as not used for locking.
Workaround    
  
Reference2177366
Problem I'm getting the "ORA-01786: FOR UPDATE of this query expression is not allowed" error when I run my app.
Description If you are using the Pessimistic Locking mode, and you are using batch fauling or prefetching of relationships, EOF can generate a SQL statement like the following:
<OracleSQLExpression: "SELECT DISTINCT t0.CATEGORY, t0.DATE_RELEASED, t0.LANGUAGE, t0.MOVIE_ID, t0.RATING, t0.REVENUE, t0.STUDIO_ID, t0.TITLE FROM DIRECTOR t1, MOVIE t0 WHERE t1.TALENT_ID = :talentID AND t0.MOVIE_ID = t1.MOVIE_ID FOR UPDATE" withBindings:{talentID = 87; }>

This statement with fail with the ORA-01786 error. The Oracle RDBMS doesn't support the use of DISTINCT with the FOR UPDATE clause.
Workaround     If you must use the Pessimistic locking mode against an Oracle database, you will not be able to use the batch faulting or prefetching features.
  
Reference2162425
Problem Oracle Adaptor doesn't read stored procedures inside of packages.
Description There is no way to get the database to tell you the components (procedures and functions) that are inside a package definition. Clients can still create stored procedures in the model that will call into packages, it's just that model description using EOModeler won't create these at connect time.
Workaround     You can use EOModeler to create the stored procedure definitions in the model. Just set the external name of the stored procedure to package-name.procedure-name.
  

Informix Adaptor
Reference2281550
Problem The Informix client library cannot be called from multiple threads
Description On Windows NT, a multi-threaded application that uses the Informix client library produces an error of the form "Informix Error -180 no connection". On Solaris, a different error is produced. The Informix client library cannot be called from multiple threads.
Workaround     Run you application with WOWorkerThreadCount set to 0 or 1 on NT, and 0 on Solaris.
  
Reference2239652
Problem Can't create an Informix database from within EOModeler
Description Creation of a new Informix database from within EOModeler generates a "Not able to create a database during an explicit database connection" error. This is due to the fact that the Informix API won't let you create a new database once you've specified that you're using an existing one; the EOInformixAdaptor as currently implemented always specifies a database when it connects.
Workaround     Copy the database creation statements out of the SQL text area and paste them into a tool like dbaccess.
  
Reference2170232
Problem Informix adaptor raises an exception when you try to sort on attributes that are not in the select list
Description Due to a restriction in the Informix adaptor, it's not possible to sort on attributes that aren't included in the select list. This means that it isn't possible to sort the results using an attribute that's not marked on the entity as either a primary key, used for locking, or a class property.
Workaround     If possible, add the attribute to the entity and mark it as used for locking. Otherwise, there is no workaround.
  

ODBC Adaptor
Reference2226610
Problem Some bugs in old versions of the ODBCJT32.DLL (used to access Microsoft Access) can cause problems with primary key generation in the ODBC Adaptor.
Description The ODBC manager reports an invalid SQL statement when updating the EO_PK_TABLE. ODBCJT32.DLL version 3.40.2728 causes this problem, but the more recent ODBCJT32.DLL version 3.51.1029 works correctly. The ODBC Control Panel can be used to check the version of the ODBC drivers installed on a Windows NT machine. Open the ODBC Control Panel and click on the tab labeled "ODBC Drivers".
Workaround     The latest ODBC manager and drivers for Windows NT are available from Microsoft. See <http://www.microsoft.com/data/mdac15.htm>.
  

  Enterprise Objects Framework 3.0   Copyright 1998 by Apple Computer, Inc. All Rights Reserved.