Difference between revisions of "OpenDBX/C API/odbx bind"
(Description) |
(Merged and extended description and parameter sections) |
||
| Line 13: | Line 13: | ||
odbx_t* '''handle''', | odbx_t* '''handle''', | ||
const char* '''database''', | const char* '''database''', | ||
| − | const char* ''' | + | const char* '''who''', |
| − | const char* ''' | + | const char* '''cred''' ) |
= Description = | = Description = | ||
| Line 20: | Line 20: | ||
'''odbx_bind()''' associates a connection created by [[OpenDBX_init|odbx_init()]] to a specific database instance after the server verified and accepted the authentication details. All further operations will (normally) only affect the tables and records within this database instance. They may be limited to certain subset depending on the privileges granted to the given user account. If binding to the database instance succeeded, '''odbx_bind()''' also enables compatibility to the ANSI SQL standard if this is possible for the database server implementation. | '''odbx_bind()''' associates a connection created by [[OpenDBX_init|odbx_init()]] to a specific database instance after the server verified and accepted the authentication details. All further operations will (normally) only affect the tables and records within this database instance. They may be limited to certain subset depending on the privileges granted to the given user account. If binding to the database instance succeeded, '''odbx_bind()''' also enables compatibility to the ANSI SQL standard if this is possible for the database server implementation. | ||
| − | '''odbx_bind_simple()''' performs the same tasks as '''odbx_bind()''' but can't do anything else than simple | + | '''odbx_bind_simple()''' performs the same tasks as '''odbx_bind()''' but can't do anything else than simple user name / password authentication. It shouldn't be used in applications linking to the OpenDBX library version 1.1.1 or later and it will be removed from the library at a later stage. |
| − | + | Both functions accept almost the same parameters. The '''handle''' parameter always has to be a pointer to a valid connection object allocated by [[OpenDBX_init|odbx_init()]]. The availability of certain options or the behavior of the connection associated to the given connection reference can be changed by calling [[OpenDBX_get_option|odbx_get_option()]] respectively [[OpenDBX_set_option|odbx_set_option()]] but this must be done before calling '''odbx_bind()'''. Examples of such options are the thread-safetiness of the native database client library or to enable support for sending multiple statements at once. | |
| − | + | '''database''' is necessary to let the database server know which database instance should be used for executing all further requests. In combination with the authentication parameters '''who''' and '''cred''', it usually allows or denies operations on tables and records within this database instance. Contrary to that, SQLite doesn't use '''who''' and '''cred''' but instead relies on the file system permissions to grant access to the whole database file. If they are used, the supplied values for all three parameters must be zero-terminated strings and should be in exactly the same character case as stored by the database manager. Otherwise, they can also be NULL. Some database libraries also support the use of default values provided by a configuration file if a parameter is NULL. | |
| − | + | '''method''' specifies the mechanism for authenticating a user account before it can perform operations on tables and records. Currently, all database backend modules only support the ODBX_BIND_SIMPLE method which provides basic user name / password authentication. In this case, the parameter '''who''' must be the name of an user account while '''cred''' has to be the password that belongs to the given account. | |
| − | + | An already associated connection object can be detached from the database and rebound to the same database server. It is possible to bind it to another database instance, with another user account and other options by detaching the connection object with [[OpenDBX_unbind|odbx_unbind()]] first before invoking '''odbx_bind()''' with the same or with different parameters again. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
= Errors = | = Errors = | ||
Revision as of 19:19, 18 February 2007
#include <odbx.h>
int odbx_bind(
odbx_t* handle,
const char* database,
const char* who,
const char* cred,
int method )
int odbx_bind_simple(
odbx_t* handle,
const char* database,
const char* who,
const char* cred )
Description
odbx_bind() associates a connection created by odbx_init() to a specific database instance after the server verified and accepted the authentication details. All further operations will (normally) only affect the tables and records within this database instance. They may be limited to certain subset depending on the privileges granted to the given user account. If binding to the database instance succeeded, odbx_bind() also enables compatibility to the ANSI SQL standard if this is possible for the database server implementation.
odbx_bind_simple() performs the same tasks as odbx_bind() but can't do anything else than simple user name / password authentication. It shouldn't be used in applications linking to the OpenDBX library version 1.1.1 or later and it will be removed from the library at a later stage.
Both functions accept almost the same parameters. The handle parameter always has to be a pointer to a valid connection object allocated by odbx_init(). The availability of certain options or the behavior of the connection associated to the given connection reference can be changed by calling odbx_get_option() respectively odbx_set_option() but this must be done before calling odbx_bind(). Examples of such options are the thread-safetiness of the native database client library or to enable support for sending multiple statements at once.
database is necessary to let the database server know which database instance should be used for executing all further requests. In combination with the authentication parameters who and cred, it usually allows or denies operations on tables and records within this database instance. Contrary to that, SQLite doesn't use who and cred but instead relies on the file system permissions to grant access to the whole database file. If they are used, the supplied values for all three parameters must be zero-terminated strings and should be in exactly the same character case as stored by the database manager. Otherwise, they can also be NULL. Some database libraries also support the use of default values provided by a configuration file if a parameter is NULL.
method specifies the mechanism for authenticating a user account before it can perform operations on tables and records. Currently, all database backend modules only support the ODBX_BIND_SIMPLE method which provides basic user name / password authentication. In this case, the parameter who must be the name of an user account while cred has to be the password that belongs to the given account.
An already associated connection object can be detached from the database and rebound to the same database server. It is possible to bind it to another database instance, with another user account and other options by detaching the connection object with odbx_unbind() first before invoking odbx_bind() with the same or with different parameters again.
Errors
- -ODBX_ERR_BACKEND: Any error occured in the backend
- -ODBX_ERR_PARAM: One of the parameters is NULL or handle is invalid
- -ODBX_ERR_NOMEM: Allocating new memory failed
- -ODBX_ERR_TOOLONG: The length of a string exceeded the buffer size
See also
Back to Overview
