See the following:

http://www.elevatesoft.com/dbisam4d7_dbisam_architecture.htm

Lauchlan M wrote:

> And the main initial reason for dropping the Engine component in C/S
> apps would be for changing the default server name?


No.  You only need the Engine component on the client app if you will
also be running in local mode AND want to access some properties or
events of the engine itself such as trigger handlers or other events.
Placing the Engine component in the client app is strictly optional.
If you choose not to include the DbisamEngine component a default
DbisamEngine Component will be instantiated anyway.  Sames goes for a
DbiSamSesstion component.


>
> Is it typically used for local apps?

only if you need to aqccess properties and events of the DbisamEngine.
Note that if you have a C/S app and have included triggers or server
procs and there is a chance that your client will run in local mode
(even if accessing the data on your server via direct access rather
then via a DbisamServer) then you need to add the Engine to your client
application and add your triggers/proces to your cliet app as well.
Again, this is why it is a good idea to separate your triggers / procs
to separate .pas files (or even packages) so that they can be resused
in both the server and client applications.

Lauchlan M wrote:

> 1. when I put the session into stlocal, the database component still
> demands I enter a databasename. If this is embedded mode, why do I
> need an 'Alias'?

In local mode just use the DbisamDatabase DIRECTORY prop to fill in the
path to the data , or I believe if the database tables are in the
application directory it will find them automatically.  You do need to
fill in the DATABASENAME property so that you can wire tables back to
the right Database component.  This works just like the BDE.  if using
the default session then you do not need to explicitly set the session
property of your DbisamQuery or DbisamTable components but I think it
is a good idea to do it anyway.

Example:

DbisamSession.SessionType := stLocal;
DbisamSession.SessionName := 'MySession';
.....
.....

DbisamDatabase1.SessionName := 'MySession';
DbisamDatabase1.Directory := 'C\SomePath\MyDataFolder';
DbisamDatabase1.DatabaseName = 'MyData';
.....
.....
....

DbisamQuery1.SessionName := 'MySession';
DbisamQuery1.DatabaseName := 'MyData';
.....
.....


Now as mentioned previously you can leave off the Session Component and
even the Database component if you will never scale your app up to C/S
but I find that it makes sense to include it anyway so that you need
not code change to move to C/S, plus you could have different sesssions
if you wanted to.  I use the default session for private tables.


>
> 2. It was complaining in embedded mode when I used the default
> session name.  When I changed it to 'Fred' it worked. Not sure what
> was going on there.

If you are using a session component then you need to give it a
SessionName.


>
> 3. I guess I must be a bit confused about what DatabaseName is - if
> it's an Alias, why would one still need to choose the database in
> RemoteDataBase?  Wouldn't the Alias/Databasename specify this already?


see my comments above.


>
> 4. All this was without dropping the DBISAMEngine component. Is this
> not needed, even for embedded apps?


No, it is optional.  See my previous post.

>
> 5. Where do I enter usernames and passwords, so that it doesn't give
> me the username and password dialog in C/S mode?

In the DbisamSession component

RemoteUser
RemotePassword

Lauchlan,

<< I notice that the components are roughly similar to Nexus - table/query,
session, database, engine, etc - so that part should be fine once I work out
which properties are required (presumably a path or alias?). >>

You can actually use the TDBISAMTable and TDBISAMQuery components directly
without the TDBISAMSession and TDBISAMDatabase components if only using
local/direct access and not C/S access.  But with C/S access, you need a
TDBISAMSession component for the remote session.  The TDBISAMDatabase
component is still optional - you have the option of putting the logical
remote database name in the TDBISAMDatabase.RemoteDatabase property and then
having all of the TDBISAMTable/TDBISAMQuery components point to the assigned
TDBISAMDatabase.DatabaseName (user-defined) via their DatabaseName
properties, or you can put the logical remote database name directly into
the DatabaseName property of the TDBISAMTable/TDBISAMQuery components and
skip the TDBISAMDatabse component altogether.

I've attached the basic hook-ups for a C/S application in a Delphi form.

<< What I am more confused by is how to use the equivalent of NexusDB's
'Enterprise Manager' tool to create the databasaes and tables, and run the
server (in the c/s app).

As I see it, I have two tools - dbsys and servadmin.

I see that dbsys lets me create tables, but it's not clear how to
create/define databases. The tool by default seems to create the tables in
memory. >>

You have to use the Server Administration Utility to create the databases
and assign rights to the databases.  Logical database names and user rights
only exist on the database server for C/S applications, and not for local
applications that use direct access.  If you log into the database server
using the Server Administration Utility, you can navigate to the Databases
tab and add a new database there.

<< On the other hand, servadmin lets me work with servers (databases?), but
apparently not create or edit databases or tables. >>

Correct.  Once you have defined the database using the Server Administration
Utility, you can then use the Database System Utility to do anything else
with the database in terms of creating tables, querying tables, etc.

<< Also, Nexus has client/server and embedded - what are the DBOSAM
equivalents? >>

DBISAM can do single-user direct access, multi-user direct access
(file-sharing), and remote C/S access.  The first and third options are the
equivalent to the options provided by NexusDB.

--
Tim Young
Elevate Software
www.elevatesoft.com

Lauchlan,

<< great! But that's lots of files . . . I thought it was a streytch in
nexus with just one file per table! Anyway, I'm sure there's a reason .
>>

Most of it has to do with the fact that DBISAM still provides multi-user
direct access.   It puts some limitations on how "variable-length" you can
get with the file structures and not run into performance or physical
locking issues.

<< Another couple of newbie questions - what are the default username and
passwords for the server, and where do I configure these? Also, where do I
configure the users? >>

You can always find them here in the manual:

http://www.elevatesoft.com/dbisam4d5_configuring_starting_server.htm

under "Default Login Information".

--
Tim Young
Elevate Software
www.elevatesoft.com

Lauchlan,

<< 1. when I put the session into stlocal, the database component still
demands I enter a databasename. If this is embedded mode, why do I need an
'Alias'? >>

The TDBISAMDatabase acts as a database conduit, and DBISAM uses the
user-defined DatabaseName property for hooking up the various
TDBISAMTable/TDBISAMQuery components to the TDBISAMDatabase component (just
like the SessionName property for the TDBISAMSession component).  The
RemoteDatabase and Directory properties are where you actually specify the
remote database and/or local/file server directory (for direct access).  You
can specify both so that, when you switch back and forth between local and
remote access via the TDBISAMSession.SessionType property, you will always
be pointing to a valid database.

<< 2. It was complaining in embedded mode when I used the default session
name. When I changed it to 'Fred' it worked. Not sure what was going on
there. >>

See my C/S hookups form that I posted in the previous message.  All
components must use the same SessionName or else certain components won't
"see" the proper databases or tables.

<< 3. I guess I must be a bit confused about what DatabaseName is - if it's
an Alias, why would one still need to choose the database in RemoteDataBase?
Wouldn't the Alias/Databasename specify this already? >>

See above.

<< 4. All this was without dropping the DBISAMEngine component. Is this not
needed, even for embedded apps? >>

It's optional, and only necessary if you wish to customize the engine at
design-time.

<< 5. Where do I enter usernames and passwords, so that it doesn't give me
the username and password dialog in C/S mode? >>

Use the TDBISAMSession's RemoteUser and RemotePassword properties.

--
Tim Young
Elevate Software
www.elevatesoft.com

Lauchlan,

<< Nexus also has a Winsock transport component for the C/S case, but I
expect int he DBISAM case this is just internalised to use tcp/ip here
without dropping that component specifically? In any case, I don't see a
component for that . . . >>

Actually, Winsock is only used with remote C/S access.  Local access is just
that - direct and local with no transport layer at all.

--
Tim Young
Elevate Software
www.elevatesoft.com