An BDE-based application's database connections, drivers, cursors, queries, and so on are maintained within the context of one or more BDE sessions. Sessions isolate a set of database access operations, such as database connections, without the need to start another instance of the application. 

All BDE-based database applications automatically include a default session component, named Session, that encapsulates the default BDE session. When database components are added to the application, they are automatically associated with the default session (note that its SessionName is "Default"). The default session provides global control over all database components not associated with another session, whether they are implicit (created by the session at runtime when you open a dataset that is not associated with a database component you create) or persistent (explicitly created by your application). The default session is not visible in your data module or form at design time, but you can access its properties and methods in your code at runtime. 

To use the default session, you need write no code unless your application must

• Explicitly activate or deactivate a session, enabling or disabling the session's databases' ability to open.
• Modify the properties of the session, such as specifying default properties for implicitly generated database components.
• Execute a session's methods, such as managing database connections (for example opening and closing database connections in response to user actions).
• Respond to session events, such as when the application attempts to access a password-protected Paradox or dBASE table.
• Set Paradox directory locations such as the NetFileDir property to access Paradox tables on a network and the PrivateDir property to a local hard drive to speed performance.
• Manage the BDE aliases that describe possible database connection configurations for databases and datasets that use the session.

Whether you add database components to an application at design time or create them dynamically at runtime, they are automatically associated with the default session unless you specifically assign them to a different session. If you open a dataset that is not associated with a database component, Delphi automatically

• Creates a database component for it at runtime.
• Associates the database component with the default session.
• Initializes some of the database component's key properties based on the default session's properties. Among the most important of these properties is KeepConnections, which determines when database connections are maintained or dropped by an application.

The default session provides a widely applicable set of defaults that can be used as is by most applications. You need only associate a database component with an explicitly named session if the component performs a simultaneous query against a database already opened by the default session. In this case, each concurrent query must run under its own session. Multi-threaded database applications also require multiple sessions, where each thread has its own session. 

Applications can create additional session components as needed. BDE-based database applications automatically include a session list component, named Sessions, that you can use to manage all of your session components. For more information about managing multiple sessions see, Managing multiple sessions. 

You can safely place session components in data modules. If you put a data module that contains one or more session components into the Object Repository, however, make sure to set the AutoSessionName property to True to avoid namespace conflicts when users inherit from it.