Inherits From:
EOAdaptor : NSObject
Declared in: SybaseEOAdaptor/SybaseAdaptor.h
The features SybaseAdaptor adds to EOAdaptor are as follows:
The SybaseAdaptor class has these restrictions: A context can only manage one channel at a time, and the adaptor doesn't support full outer joins because the Sybase server itself doesn't support them.
The Connection Dictionary
The connection dictionary contains items needed to connect to a Sybase server, such as the server name and database (it's common to omit the user name and password from the connection dictionary, and prompt users to enter those values in a login panel). The keys of this dictionary identify the information the server expects, and the values of those keys are the values that the adaptor uses when trying to connect to the server. For Sybase databases the required keys are as follows:
hostName
databaseName
userName
password
The connection dictionary can optionally include three other keys: sybasePasswordEncryption, LC_ALL, and primitiveTypeMap. sybasePasswordEncryption provides support for Sybase password encryption. LC_ALL declares to the Sybase server the character set being used by the client (such as eucjis, ascii7, or iso_1). For a complete list of types available for this field, see your Sybase documentation. primitiveTypeMap describes the mapping of user-defined data types to their base Sybase type (such as varchar or datetime). For more information on user-defined data types, see "Data Type Mapping."
To add any of these optional keys and appropriate values to your connection dictionary, you can manually edit your model file. For example:
connectionDictionary = {databaseName = People;
hostName = "";
LC_ALL = eucjis;
password = "";
primitiveTypeMap = {id = varchar; ssn = char(9); };
sybasePasswordEncryption = YES;
userName = "";
};
Subsequently changing the connection dictionary in your model file using the Set Adaptor Info command in EOModeler has no effect on these keys and their values-they are preserved unless you edit the file to remove them. Alternatively you can add the optional keys to a model's connection dictionary programmatically.
The default character set for non-Japanese systems is iso_1 (that is, ISO Latin 1), while the default character set for Japanese systems is eucjis. You only need to add the LC_ALL key to your connection dictionary if you are using a character set other than your system's default.
Error Handling
SybaseAdaptor, SybaseContext, and SybaseChannel can raise exceptions due to programming errors that result in invalid argument values or internal inconsistencies. In addition, messages, errors, and failure status returned from the Sybase SQL Server and client libraries can also result in EOGeneralAdaptorExceptions. When an exception results from a callback to the CS_CLIENTMSG_CB (Sybase ClientMessage callback) or the CS_SERVERMSG_CB (Sybase ServerMessage callback), all of the information passed into this routine is available in the userInfo dictionary contained by the exception. When an exception is raised in response to a Sybase ClientMessage callback, you can get the information provided by the client library as follows:
clientMsgDict = [[localException userInfo]
objectForKey:@"sybaseClientMessageDictionary"];
The clientMsgDict
contains the following keys which have values corresponding to those sent in the callback function that raised the exception: msgstring, osstring, sqlstate, severity, msgnumber, osnumber, status.
Similarly, when the exception is raised in response to a Sybase ServerMessage callback, you can get the information provided by the server as follows:
svrMsgDict = [[localException userInfo]
objectForKey:@"sybaseServerMessageDictionary"];
The svrMsgDict
contains the following keys which have values corresponding to those sent in the callback function that raised the exception: text, svrname, proc, sqlstate, msgnumber, state, severity, line, status.
Locking
All adaptors use the database server's native locking facilities to lock rows on the server. The Sybase adaptor locks a row by using the HOLDLOCK keyword in SELECT statements. This occurs when:
selectAttributes:fetchSpecification:lock:entity:
message with YES specified as the value for the lock:
keyword.ockObjectWithGlobalID:editingContext:
message.
Data Type Mapping
Every adaptor provides a mapping between each server data type and the Objective-C type to which a database value will be coerced when it's fetched from the database. The following table lists the mapping used by SybaseAdaptor.
In addition, SybaseAdaptor provides a mapping for user-defined data types. For example, a custom data type partnumber defined as char(10) is mapped to NSString-the Objective-C type to which partnumber 's base data type (char) is mapped. SybaseAdaptor's implementation of describeModelWithTableNames: automatically creates mappings for user-defined data types and saves them in the connection dictionary of the newly created model. Consequently, even models created with EOModeler automatically include information about custom data types.
Since information about custom types is stored in a model's connection dictionary, the type mapping methods-externalTypesWithModel: , internalTypeForExternalType:model: , and isValidQualifierType:model: -use the model argument if it is provided. If the model argument isn't provided, these methods don't have user-defined data type information available to them.
SQL and User-Defined Transactions
Certain data definition commands, such as CREATE TABLE, can't be executed in a user-defined transaction. However, the database channel and adaptor channel require you to start a transaction before evaluating any SQL. To work around this problem, you need to send the adaptor context or database context a transactionDidBegin
message to make it think a transaction is in progress. Then you can send it the SQL statement, followed by a transactionDidCommit
message.
externalTypesWithModel:
(EOModel *)model
Overrides the EOAdaptor method externalTypesWithModel:
to return the Sybase database types.
See also: + internalTypeForExternalType:model:
internalTypeForExternalType:model:
+ (NSString *)internalTypeForExternalType:
(NSString *)extType model:
(EOModel *)model
Overrides the EOAdaptor method internalTypeForExternalType:
to return the name of the Objective-C class used to represent values stored in the database as extType.
See also: + externalTypesWithModel:
connectionKeys
Returns an NSArray containing the keys in the receiver's connection dictionary. You can use this method to prompt the user to supply values for the connection dictionary.
Copyright © 1997, Apple Computer, Inc. All rights reserved.