More questions...to anyone who can help!

I hope you'll pardon all the basic questions, but I've tried to find
information sources that answer these types of questions but so far haven't
been able to find exactly what I need! As I'm using Nexus as my first foray
into "real" database design, much of what I need to know may be generic, but
when I ask such questions elsewhere I'm always told to go back to the db
engine maker! Up till now everything I've done has been centered around
TClientDataSets...I never got around to doing much more than a simple
embedded single-exe with FF so it's like I'm starting at the beginning!

1. First, your manual shows the three different ways one can create
tables, and I believe I understand the main points of each, however I'm
curious as to exactly what benefits are provided by using a DataDictionary
to do so because the code is not much less than simply doing FieldDefs in
code such as shown in your single-exe example from the quick-start guide.
Is this merely so that the creation of tables can be setup in a seperate
unit for extensibility, or are their benefits within the general application
as well?

2. Although I have a working single-exe project working that uses a group
of data-aware edits to allow the display and editing of fields I've set up
at design-time in my table. I've set StoreDefs to true, and when my
mainform is created I do a check via "If nxTable1.Exists = True" to find out
if indeed a table file already exists in the set directory alias. If so I
load it, but if not, I create it via nxTable1.CreateTable(). The problem is
that although I set up the field definitions at design-time I was not able
to "Hook" my data-aware components up to their respective fields at
design-time as I wanted because no table yet existed...or so the error I
received indicated. Yet your manual alludes to the fact, but does not show
how, this CAN indeed be done. Please tell me how as I'm stuck at this
point!

3. I'm not sure I really understand exactly how aliases work, and finding
any info on the subject seems to be impossible! Speaking in terms of the
same application as above, I also wanted to set my alias path and/or name at
runtime so that I could query the user as to what directory they wanted
their table files stored within. The reason for this is that as a
single-exe application I want whatever user logs onto the system and starts
the app to be able to create and/or load up their own table files...although
they will ALL be defined exactly the same way as per the stored Definitions.
But again, I could not get my app to startup and create a table unless I
actually hard-coded it's alias path into the component property at
design-time. Nothing would hook up if I merely did it in code as I wanted.
How is this properly accomplished? And then how do I manage it so that each
user can name his or her table files as wanted as well as have them created
in the directory of their choice?

4. Block Sizes: As Nexus allows me to set the block sizes at table
creation time via CreateTableEx(), I wanted to understand better what the
considerations are for setting the block size to any particular figure.
What does it depend upon? The type and size of fields employed? The number
of records assumed as a max? How does block size affect speed, caching,
etc. Is just one block cached at a time when reading a table record?

5. When using a single-exe model such as I am, how does caching work?
How about the updating of records? For example, let's say I have two tables
opened in this application...the first or main controlling table will have
only a minimal number of records, no more than 500, comprised of less than
25 fields of mixed basic types. Most of these will be strings of 30 or 255
in length. This table will remain open for the life of the application
session. The second table will actually be created and/or loaded
dynamically depending upon if the user wants to for a particular record
being displayed in the main table. So there might be anywhere from 1 to 500
seperate database tables that will need to be stored and named as per user
settings, and which are created/loaded dynamically as needed. Only one of
these secondary tables will ever be open at any particular time of course,
with them being closed and unloaded before another one is loaded and opened.
Again they will be quite simple in structure with less than 25 fields of
basic standard types. This is very simple to do with a TClientDataSet but
it gets confusing with Nexus! Can I accomplish this with just the one
embedded server? Do I need a seperate database and table component for each
possible table or, since they will all be exactly alike anyway, can I use of
each and merely change the alias name and/or directory as needed? I believe
the latter is the case but I'm not sure. How can I tell how much of a
particular table's file is actually loaded into memory when it is
loaded/created? Does this depend upon the block size?

Again I apologize for the basic questions. I realize you're not here to
teach me how to design databases. I've just become exasperated trying to
find this kind of info out! All the books and examples I find only are
based on generic methods that although being pretty self-explanatory, do not
answer my questions! I can't believe that no one has written any kind of
tutorial that really explains how all these things work together! What I
get in response from most is that because of the differences apparent
between engines, it's impossible to respond to questions like this without
thorough knowledge of the system being used. I think that may indeed be
true to a point, but there is still a lot of unanswered questions that could
be no matter what engine is used! If you know of any good informational
resources, please tell me!
Anyway, any help will be greatly appreciated. Maybe I'll write my own
tutorial for beginners when I finally understand it all so that they don't
have to go thru what I have! Thanx in advance!

Robert Meek wrote:
> as to exactly what benefits are provided by using a DataDictionary
> to do so

You have more control. For example, you can make the index ascending one
field and descending on another. You can also set the locale for sorting
strings.

> 2. Although I have a working single-exe project working that uses a group
> of data-aware edits to allow the display and editing of fields I've set up
> at design-time in my table. I've set StoreDefs to true, and when my
> mainform is created I do a check via "If nxTable1.Exists = True" to find out
> if indeed a table file already exists in the set directory alias. If so I
> load it, but if not, I create it via nxTable1.CreateTable(). The problem is
> that although I set up the field definitions at design-time I was not able
> to "Hook" my data-aware components up to their respective fields at
> design-time as I wanted because no table yet existed...or so the error I
> received indicated. Yet your manual alludes to the fact, but does not show
> how, this CAN indeed be done. Please tell me how as I'm stuck at this
> point!

Most people use the Enterprise Manager to create their tables. I always
create mine in code, so if I want to create persistent fields, I build
enough of the app that I can run it and create the tables, then open
Delphi and let the IDE create the persistent fields.

I feel compelled to point out that this is another time that _not_ using
data-aware controls is actually simpler.

> 3. I'm not sure I really understand exactly how aliases work, and finding
> any info on the subject seems to be impossible! Speaking in terms of the
> same application as above, I also wanted to set my alias path and/or name at
> runtime so that I could query the user as to what directory they wanted
> their table files stored within. The reason for this is that as a
> single-exe application I want whatever user logs onto the system and starts
> the app to be able to create and/or load up their own table files...although
> they will ALL be defined exactly the same way as per the stored Definitions.
> But again, I could not get my app to startup and create a table unless I
> actually hard-coded it's alias path into the component property at
> design-time. Nothing would hook up if I merely did it in code as I wanted.
> How is this properly accomplished? And then how do I manage it so that each
> user can name his or her table files as wanted as well as have them created
> in the directory of their choice?

I'm afraid I don't follow this. Are you saying you have a single-user
embedded server app, but you don't know how to set the database path at
runtime?

--
David Marcus

First of all, Thanx for answering! <g>
You mention using the EM to create tables. yes, I've also tried this
but then of course one would have to provide an empty table with the
original install and that adds to the problems of having it installed where
each new user might wish to have their own! Also, what happens if the table
file you originally install becomes corrupted or deleted? There would be no
way to re-create it from scratch!
You're right of course, NOT using data-aware components or Grids
certainly would solve this problem! But just so I'm sure on this
point...what you are saying then is that there is indeed NO way of doing it?
What about connecting the data-aware controls after the table is first
created...in code? For example, could I do something like this:

Grid,Columns.AddAll;

After the table has been created and the dir alias set? I looked but
couldn't find the proper calls to do what I wanted, but perhaps I missed
them or there's a better way of doing it. The reason I'd like to be able to
do it this way is that in some circumstances data-aware controls are simply
much easier to work with on the client side of things. Certainly a lot less
coding! Actually I believe hooking basic data-aware controls like edits
wouldn't be a problem because all I would have to do is set the dataset and
filed properties, but how would I do this with a Grid? If I set just the
dataset properties, would it then automatically create a column for each
field? And if so, how do tell it NOT to create columns for certain fields,
like a memo field I wouldn't want to show in the Grid, or change the visible
order of the columns...or the titles shown?

As to the database path, I realize that with an embedded single-exe you MUST
use a alias directory path, and if I solve the problems above, I can ask the
user where he or she wants it and then set it in code, but what about table
names? For example, can I set a new alias name in code at the same time I
set the alias path and then use it to check if it exists or not and if I
need to create a new table file with that name and in that directory?
Remembering that each potential user, ( only one at a time ), will have his
or her own table file that will be created/loaded based on their
information...probably held in a dat file...as per the currently logged onto
system name. I know I'm explaining this badly! <g> OR am I not actually
able to give each user their own "Named" table file(s)?
Thanx again!

"David Marcus" <> wrote in message
news:MPG.19a5d4f17a7d797c989719@news.nexusdb.com.. .
> Robert Meek wrote:
> > as to exactly what benefits are provided by using a DataDictionary
> > to do so
>
> You have more control. For example, you can make the index ascending one
> field and descending on another. You can also set the locale for sorting
> strings.
>
> > 2. Although I have a working single-exe project working that uses a
group
> > of data-aware edits to allow the display and editing of fields I've set
up
> > at design-time in my table. I've set StoreDefs to true, and when my
> > mainform is created I do a check via "If nxTable1.Exists = True" to find
out
> > if indeed a table file already exists in the set directory alias. If so
I
> > load it, but if not, I create it via nxTable1.CreateTable(). The
problem is
> > that although I set up the field definitions at design-time I was not
able
> > to "Hook" my data-aware components up to their respective fields at
> > design-time as I wanted because no table yet existed...or so the error I
> > received indicated. Yet your manual alludes to the fact, but does not
show
> > how, this CAN indeed be done. Please tell me how as I'm stuck at this
> > point!
>
> Most people use the Enterprise Manager to create their tables. I always
> create mine in code, so if I want to create persistent fields, I build
> enough of the app that I can run it and create the tables, then open
> Delphi and let the IDE create the persistent fields.
>
> I feel compelled to point out that this is another time that _not_ using
> data-aware controls is actually simpler.
>
> > 3. I'm not sure I really understand exactly how aliases work, and
finding
> > any info on the subject seems to be impossible! Speaking in terms of
the
> > same application as above, I also wanted to set my alias path and/or
name at
> > runtime so that I could query the user as to what directory they wanted
> > their table files stored within. The reason for this is that as a
> > single-exe application I want whatever user logs onto the system and
starts
> > the app to be able to create and/or load up their own table
files...although
> > they will ALL be defined exactly the same way as per the stored
Definitions.
> > But again, I could not get my app to startup and create a table unless I
> > actually hard-coded it's alias path into the component property at
> > design-time. Nothing would hook up if I merely did it in code as I
wanted.
> > How is this properly accomplished? And then how do I manage it so that
each
> > user can name his or her table files as wanted as well as have them
created
> > in the directory of their choice?
>
> I'm afraid I don't follow this. Are you saying you have a single-user
> embedded server app, but you don't know how to set the database path at
> runtime?
>
> --
> David Marcus

hi

ok, lets give it a try from a not too technical point of view

> 1. First, your manual shows the three different ways one can create

as David Marcus answered it gives you much more control over how an index is
created. in short: using the indexdefs and createtable is the shortcut for
creating it and mainly there for compatibility with borlands TDataset. the
datadacitionary is more complicated, but much much more flexible and lets not
forget this: it's extendable with your own sub engines for indexing.

> 2. Although I have a working single-exe project working that uses a group

that one is a problem of concepts. if you go the coding way, you have to go it
fully. what i mean is: if you create tables in code at runtime, you also have
to link the dataaware components at runtime. Also remember that as soon as you
create persistent fields (at designtime or runtime) you can work with them
ONLY. the vcl client components do not simultanous use of both persistent and
non-persistent fields.
if i understand waht you want to do correctly then you hav to set the
datasource.dataset property at runtime to point to your created table instance.
you can set the datasource and fieldname properites at designtime EVEN if the
according table does not exist. naturally you can't activate components
(tables, databases) at designtime cause they are not created still ...

> 3. I'm not sure I really understand exactly how aliases work, and finding

first thing to make clear is: AliasPath and AliasName are mutually exclusive.
another thing is: Database and AliasName for tables/queries is mutually
exclusive too. this said the proper way to do it is to add TnxDatabase and
point its AliasName to an Alias created on the server. If you are working
embedded (even at designtime) you naturally can't activate the database
pointing to it, because the alias does not exist. you have to create it in code
BEFORE you try to activate anything that connects to it (databases, tables,
queries). This is done from the according TnxSession methods. if you want then
an aliasname is nothing else than a shortcut for a directory (whihch you can
alternatively use via the AliasPath property, BUT i strongly recommend using
AliasName and setting this up. it makes maintanance and patch changes so much
easier).

> 4. Block Sizes: As Nexus allows me to set the block sizes at table

actually quite easy to answer. NexusDB needs to be able to store ONE record
into ONE block and ONE block is read at at one time. in general: the more
records you can fit into one block the faster sequential access to the table
is. how fast non-sequential access is, is dependent on the general issues like
filesystem blocksize, harddisk speed, location of block on the harddrive,
harddisk cache size, ...

> 5. When using a single-exe model such as I am, how does caching work?

if you are using embedded stay away from any sorts of extra caching like
3rdparty memtables, blockreadsize and the like. the embedded is highly
optimized and together with (system+hardware) disk caches and a correct sized
MaxRamSize (if possible about the size or bigger than the complete database) it
will resemble access tiems of pure memory tables.

Regarding your creation of 100s of tables (one or more for each user) i think
that should be avoidable with a good database design. if you let us know what
you want to achieve and what should be stored for users (and especially how
this is different from user to user) we might help you to get this into a
relational model that avoids the creation of user specific tables.
--

Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm

Robert, i think i begin to understand you main problem. You're not separating
between development/designtime and runtim/deployment.

Please stop the way of thinking you're in right know, step a bit back and look
at it a bit different (i don't mean to offend, please don't misunderstand):
these two (designtime&runtime) are two completely different things. you can
happily create your tables using EM and hook everything at designtime using a
dedicated server and a remoteservengine. create you complete product on this
basis. even the code for checking/creating tables at runtime will work
correctly.

if you want to have an embedded version simple add a TServerEngine (and if
needed a TSQLEngine and other serverside components) and just hook the
ServerEngine property of the Session to it instead of the remoteengine. the
only additional thing you have to do is adding one line of code to setup the
alias of the now embedded serverengine.

if you don't want to provide empty tables with your intall that is a pure
deployment decision. you can easily achieve this by just adding some code that
creates them if they are not there when the application starts. you don't need
to deal with creation of TnxTable instances and the like, just make sure that
the files exist.

in short if want to deploy a ready developed c/s solution as embedded without
adding tables do this:

* make sure your app runs fine in c/s mode
* add a TServerEngine (ServerEngine1) and other needed server side components
to your datamodule and hook them up correctly (don't change the ServerEngine
property of the Session right here!)
* make sure ActiveDesignTime is FALSE for all NexusDB components
* create a function CheckAndCreateTables to your datamodule that holds the code
for creating
* add an OnCreate event handler to you datamodule
* add a Session.ServerEngine:=ServerEngine1
* add a Session.Open;
* add a Session.AddAlias('YourAliasName', 'Your AliasPath');
* add a call to the CheckAndCreateTables
* open your tables/queries wanted

if you agree to deploy tables, turning a designtime created c/s application
just takes a couple of minutes <g>

--

Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm



"Robert Meek" <rmeek1@comcast.net> wrote in message news:3f3c200a$1@wic040d....
> First of all, Thanx for answering! <g>
> You mention using the EM to create tables. yes, I've also tried this
> but then of course one would have to provide an empty table with the
> original install and that adds to the problems of having it installed where
> each new user might wish to have their own! Also, what happens if the table
> file you originally install becomes corrupted or deleted? There would be no
> way to re-create it from scratch!
> You're right of course, NOT using data-aware components or Grids
> certainly would solve this problem! But just so I'm sure on this
> point...what you are saying then is that there is indeed NO way of doing it?
> What about connecting the data-aware controls after the table is first
> created...in code? For example, could I do something like this:
>
> Grid,Columns.AddAll;
>
> After the table has been created and the dir alias set? I looked but
> couldn't find the proper calls to do what I wanted, but perhaps I missed
> them or there's a better way of doing it. The reason I'd like to be able to
> do it this way is that in some circumstances data-aware controls are simply
> much easier to work with on the client side of things. Certainly a lot less
> coding! Actually I believe hooking basic data-aware controls like edits
> wouldn't be a problem because all I would have to do is set the dataset and
> filed properties, but how would I do this with a Grid? If I set just the
> dataset properties, would it then automatically create a column for each
> field? And if so, how do tell it NOT to create columns for certain fields,
> like a memo field I wouldn't want to show in the Grid, or change the visible
> order of the columns...or the titles shown?
>
> As to the database path, I realize that with an embedded single-exe you MUST
> use a alias directory path, and if I solve the problems above, I can ask the
> user where he or she wants it and then set it in code, but what about table
> names? For example, can I set a new alias name in code at the same time I
> set the alias path and then use it to check if it exists or not and if I
> need to create a new table file with that name and in that directory?
> Remembering that each potential user, ( only one at a time ), will have his
> or her own table file that will be created/loaded based on their
> information...probably held in a dat file...as per the currently logged onto
> system name. I know I'm explaining this badly! <g> OR am I not actually
> able to give each user their own "Named" table file(s)?
> Thanx again!
>
> "David Marcus" <> wrote in message
> news:MPG.19a5d4f17a7d797c989719@news.nexusdb.com.. .
> > Robert Meek wrote:
> > > as to exactly what benefits are provided by using a DataDictionary
> > > to do so
> >
> > You have more control. For example, you can make the index ascending one
> > field and descending on another. You can also set the locale for sorting
> > strings.
> >
> > > 2. Although I have a working single-exe project working that uses a
> group
> > > of data-aware edits to allow the display and editing of fields I've set
> up
> > > at design-time in my table. I've set StoreDefs to true, and when my
> > > mainform is created I do a check via "If nxTable1.Exists = True" to find
> out
> > > if indeed a table file already exists in the set directory alias. If so
> I
> > > load it, but if not, I create it via nxTable1.CreateTable(). The
> problem is
> > > that although I set up the field definitions at design-time I was not
> able
> > > to "Hook" my data-aware components up to their respective fields at
> > > design-time as I wanted because no table yet existed...or so the error I
> > > received indicated. Yet your manual alludes to the fact, but does not
> show
> > > how, this CAN indeed be done. Please tell me how as I'm stuck at this
> > > point!
> >
> > Most people use the Enterprise Manager to create their tables. I always
> > create mine in code, so if I want to create persistent fields, I build
> > enough of the app that I can run it and create the tables, then open
> > Delphi and let the IDE create the persistent fields.
> >
> > I feel compelled to point out that this is another time that _not_ using
> > data-aware controls is actually simpler.
> >
> > > 3. I'm not sure I really understand exactly how aliases work, and
> finding
> > > any info on the subject seems to be impossible! Speaking in terms of
> the
> > > same application as above, I also wanted to set my alias path and/or
> name at
> > > runtime so that I could query the user as to what directory they wanted
> > > their table files stored within. The reason for this is that as a
> > > single-exe application I want whatever user logs onto the system and
> starts
> > > the app to be able to create and/or load up their own table
> files...although
> > > they will ALL be defined exactly the same way as per the stored
> Definitions.
> > > But again, I could not get my app to startup and create a table unless I
> > > actually hard-coded it's alias path into the component property at
> > > design-time. Nothing would hook up if I merely did it in code as I
> wanted.
> > > How is this properly accomplished? And then how do I manage it so that
> each
> > > user can name his or her table files as wanted as well as have them
> created
> > > in the directory of their choice?
> >
> > I'm afraid I don't follow this. Are you saying you have a single-user
> > embedded server app, but you don't know how to set the database path at
> > runtime?
> >
> > --
> > David Marcus
>
>

Hannes Danzl[NDD] wrote:
> Regarding your creation of 100s of tables (one or more for each user) i think
> that should be avoidable with a good database design. if you let us know what
> you want to achieve and what should be stored for users (and especially how
> this is different from user to user) we might help you to get this into a
> relational model that avoids the creation of user specific tables.

Yes, indeed. I was going to mention that, but the question was so long,
that I got tired before I got to there.

--
David Marcus

Hannes Danzl[NDD] wrote:
> if you go the coding way, you have to go it
> fully. what i mean is: if you create tables in code at runtime, you also have
> to link the dataaware components at runtime.

You can link the data-aware components at design time, but if you
haven't created tables yet, you can't make the components active at
design time, so you won't see any data.

For that matter, you don't really need to use the IDE to create
persistent fields--it is just easier. If you look at the dfm file, you
can figure out what the IDE does.

As I said, I usually write enough code to create the tables, then fire
up the IDE and create persistent fields. If I need to add or change one
or two fields, I just edit the dfm file directly.

--
David Marcus

Thanx for the info below...you definitely cleared a couple things up I
was having trouble with...but as usual, doing so leads to more questions!
<g>
First, regarding MaxRamSize. You said it should be set about the size
of the database. You mean all table files? If so then that's going to
change as records are added so I'm a bit confused as to how to set this if
at all.
I finally figured out it's an all or nothing approach when it comes to
coding your fields and setting dataset properties at runtime or design-time,
but you say below that one can still set the fields even though no table yet
exists, which is exactly what I'm trying to do and cannot. When I set the
dataset property, I'm okay, but as soon as I attempt to add a field via the
table's designer I get an error dialog telling me that there is no database
or no table! It seems I get one or the other depending upon if I set the
alias directory at design-time or not. and I don't want to be cause this
should be set as per the user's discretion.

"Hannes Danzl[NDD]" <hannes@nexusdb.dbnexus.com> wrote in message
news:3f3c238e$1@wic040d....
> hi
>
> ok, lets give it a try from a not too technical point of view
>
> > 1. First, your manual shows the three different ways one can create
>
> as David Marcus answered it gives you much more control over how an index
is
> created. in short: using the indexdefs and createtable is the shortcut for
> creating it and mainly there for compatibility with borlands TDataset. the
> datadacitionary is more complicated, but much much more flexible and lets
not
> forget this: it's extendable with your own sub engines for indexing.
>
> > 2. Although I have a working single-exe project working that uses a
group
>
> that one is a problem of concepts. if you go the coding way, you have to
go it
> fully. what i mean is: if you create tables in code at runtime, you also
have
> to link the dataaware components at runtime. Also remember that as soon as
you
> create persistent fields (at designtime or runtime) you can work with them
> ONLY. the vcl client components do not simultanous use of both persistent
and
> non-persistent fields.
> if i understand waht you want to do correctly then you hav to set the
> datasource.dataset property at runtime to point to your created table
instance.
> you can set the datasource and fieldname properites at designtime EVEN if
the
> according table does not exist. naturally you can't activate components
> (tables, databases) at designtime cause they are not created still ...
>
> > 3. I'm not sure I really understand exactly how aliases work, and
finding
>
> first thing to make clear is: AliasPath and AliasName are mutually
exclusive.
> another thing is: Database and AliasName for tables/queries is mutually
> exclusive too. this said the proper way to do it is to add TnxDatabase and
> point its AliasName to an Alias created on the server. If you are working
> embedded (even at designtime) you naturally can't activate the database
> pointing to it, because the alias does not exist. you have to create it in
code
> BEFORE you try to activate anything that connects to it (databases,
tables,
> queries). This is done from the according TnxSession methods. if you want
then
> an aliasname is nothing else than a shortcut for a directory (whihch you
can
> alternatively use via the AliasPath property, BUT i strongly recommend
using
> AliasName and setting this up. it makes maintanance and patch changes so
much
> easier).
>
> > 4. Block Sizes: As Nexus allows me to set the block sizes at table
>
> actually quite easy to answer. NexusDB needs to be able to store ONE
record
> into ONE block and ONE block is read at at one time. in general: the more
> records you can fit into one block the faster sequential access to the
table
> is. how fast non-sequential access is, is dependent on the general issues
like
> filesystem blocksize, harddisk speed, location of block on the harddrive,
> harddisk cache size, ...
>
> > 5. When using a single-exe model such as I am, how does caching work?
>
> if you are using embedded stay away from any sorts of extra caching like
> 3rdparty memtables, blockreadsize and the like. the embedded is highly
> optimized and together with (system+hardware) disk caches and a correct
sized
> MaxRamSize (if possible about the size or bigger than the complete
database) it
> will resemble access tiems of pure memory tables.
>
> Regarding your creation of 100s of tables (one or more for each user) i
think
> that should be avoidable with a good database design. if you let us know
what
> you want to achieve and what should be stored for users (and especially
how
> this is different from user to user) we might help you to get this into a
> relational model that avoids the creation of user specific tables.
> --
>
> Hannes Danzl [NexusDB Developer]
> Newsgroup archive at http://www.tamaracka.com/search.htm
>
>

Sorry, I hate to put people to sleep! <g> My verbosity is only surpassed by
my confusion! And again I was thinking in terms of how I had set up the
original model using single-files created via a TClientDataSet. I'm reading
a book on relational database design as we speak, so hopefully I'll get a
little more understanding of what can be done with them before I get too
far, unfortunately it's all theory and no technical information is provided!
It's called "Database Design for Mere Mortals" by Michael J. Hernandez. Do
you know of it? is it any good? Do you have a better recommendation?

"David Marcus" <> wrote in message
news:MPG.19a613e3da97cfa698971a@news.nexusdb.com.. .
> Hannes Danzl[NDD] wrote:
> > Regarding your creation of 100s of tables (one or more for each user) i
think
> > that should be avoidable with a good database design. if you let us know
what
> > you want to achieve and what should be stored for users (and especially
how
> > this is different from user to user) we might help you to get this into
a
> > relational model that avoids the creation of user specific tables.
>
> Yes, indeed. I was going to mention that, but the question was so long,
> that I got tired before I got to there.
>
> --
> David Marcus

My only hesitancy to including empty tables with the install is that it
makes the application dependant upon them, and if for some reason they get
corrupted or lost then there's a major problem. I believe what I will do in
the end is use the datadictionary approach. I read quite a bit about it
last night and your examples are quite good so I shouldn't have any
problems. That way they can be created on the fl=y as needed and placed
where ever the user wants. My reasons for wanting to use the designtime
method was for speed...just to get up on the system and see how it all works
together.
Anyway I think you all for taking the time to answer my questions, and
don't ever worry about offending me! How can you offend someone who is
asking YOU for help anyway? <g>

"Hannes Danzl[NDD]" <hannes@nexusdb.dbnexus.com> wrote in message
news:3f3c2db2$1@wic040d....
> Robert, i think i begin to understand you main problem. You're not
separating
> between development/designtime and runtim/deployment.
>
> Please stop the way of thinking you're in right know, step a bit back and
look
> at it a bit different (i don't mean to offend, please don't
misunderstand):
> these two (designtime&runtime) are two completely different things. you
can
> happily create your tables using EM and hook everything at designtime
using a
> dedicated server and a remoteservengine. create you complete product on
this
> basis. even the code for checking/creating tables at runtime will work
> correctly.
>
> if you want to have an embedded version simple add a TServerEngine (and if
> needed a TSQLEngine and other serverside components) and just hook the
> ServerEngine property of the Session to it instead of the remoteengine.
the
> only additional thing you have to do is adding one line of code to setup
the
> alias of the now embedded serverengine.
>
> if you don't want to provide empty tables with your intall that is a pure
> deployment decision. you can easily achieve this by just adding some code
that
> creates them if they are not there when the application starts. you don't
need
> to deal with creation of TnxTable instances and the like, just make sure
that
> the files exist.
>
> in short if want to deploy a ready developed c/s solution as embedded
without
> adding tables do this:
>
> * make sure your app runs fine in c/s mode
> * add a TServerEngine (ServerEngine1) and other needed server side
components
> to your datamodule and hook them up correctly (don't change the
ServerEngine
> property of the Session right here!)
> * make sure ActiveDesignTime is FALSE for all NexusDB components
> * create a function CheckAndCreateTables to your datamodule that holds the
code
> for creating
> * add an OnCreate event handler to you datamodule
> * add a Session.ServerEngine:=ServerEngine1
> * add a Session.Open;
> * add a Session.AddAlias('YourAliasName', 'Your AliasPath');
> * add a call to the CheckAndCreateTables
> * open your tables/queries wanted
>
> if you agree to deploy tables, turning a designtime created c/s
application
> just takes a couple of minutes <g>
>
> --
>
> Hannes Danzl [NexusDB Developer]
> Newsgroup archive at http://www.tamaracka.com/search.htm
>
>
>
> "Robert Meek" <rmeek1@comcast.net> wrote in message
news:3f3c200a$1@wic040d....
> > First of all, Thanx for answering! <g>
> > You mention using the EM to create tables. yes, I've also tried
this
> > but then of course one would have to provide an empty table with the
> > original install and that adds to the problems of having it installed
where
> > each new user might wish to have their own! Also, what happens if the
table
> > file you originally install becomes corrupted or deleted? There would
be no
> > way to re-create it from scratch!
> > You're right of course, NOT using data-aware components or Grids
> > certainly would solve this problem! But just so I'm sure on this
> > point...what you are saying then is that there is indeed NO way of doing
it?
> > What about connecting the data-aware controls after the table is first
> > created...in code? For example, could I do something like this:
> >
> > Grid,Columns.AddAll;
> >
> > After the table has been created and the dir alias set? I looked but
> > couldn't find the proper calls to do what I wanted, but perhaps I missed
> > them or there's a better way of doing it. The reason I'd like to be
able to
> > do it this way is that in some circumstances data-aware controls are
simply
> > much easier to work with on the client side of things. Certainly a lot
less
> > coding! Actually I believe hooking basic data-aware controls like edits
> > wouldn't be a problem because all I would have to do is set the dataset
and
> > filed properties, but how would I do this with a Grid? If I set just
the
> > dataset properties, would it then automatically create a column for each
> > field? And if so, how do tell it NOT to create columns for certain
fields,
> > like a memo field I wouldn't want to show in the Grid, or change the
visible
> > order of the columns...or the titles shown?
> >
> > As to the database path, I realize that with an embedded single-exe you
MUST
> > use a alias directory path, and if I solve the problems above, I can ask
the
> > user where he or she wants it and then set it in code, but what about
table
> > names? For example, can I set a new alias name in code at the same time
I
> > set the alias path and then use it to check if it exists or not and if I
> > need to create a new table file with that name and in that directory?
> > Remembering that each potential user, ( only one at a time ), will have
his
> > or her own table file that will be created/loaded based on their
> > information...probably held in a dat file...as per the currently logged
onto
> > system name. I know I'm explaining this badly! <g> OR am I not
actually
> > able to give each user their own "Named" table file(s)?
> > Thanx again!
> >
> > "David Marcus" <> wrote in message
> > news:MPG.19a5d4f17a7d797c989719@news.nexusdb.com.. .
> > > Robert Meek wrote:
> > > > as to exactly what benefits are provided by using a DataDictionary
> > > > to do so
> > >
> > > You have more control. For example, you can make the index ascending
one
> > > field and descending on another. You can also set the locale for
sorting
> > > strings.
> > >
> > > > 2. Although I have a working single-exe project working that uses
a
> > group
> > > > of data-aware edits to allow the display and editing of fields I've
set
> > up
> > > > at design-time in my table. I've set StoreDefs to true, and when my
> > > > mainform is created I do a check via "If nxTable1.Exists = True" to
find
> > out
> > > > if indeed a table file already exists in the set directory alias.
If so
> > I
> > > > load it, but if not, I create it via nxTable1.CreateTable(). The
> > problem is
> > > > that although I set up the field definitions at design-time I was
not
> > able
> > > > to "Hook" my data-aware components up to their respective fields at
> > > > design-time as I wanted because no table yet existed...or so the
error I
> > > > received indicated. Yet your manual alludes to the fact, but does
not
> > show
> > > > how, this CAN indeed be done. Please tell me how as I'm stuck at
this
> > > > point!
> > >
> > > Most people use the Enterprise Manager to create their tables. I
always
> > > create mine in code, so if I want to create persistent fields, I build
> > > enough of the app that I can run it and create the tables, then open
> > > Delphi and let the IDE create the persistent fields.
> > >
> > > I feel compelled to point out that this is another time that _not_
using
> > > data-aware controls is actually simpler.
> > >
> > > > 3. I'm not sure I really understand exactly how aliases work, and
> > finding
> > > > any info on the subject seems to be impossible! Speaking in terms
of
> > the
> > > > same application as above, I also wanted to set my alias path and/or
> > name at
> > > > runtime so that I could query the user as to what directory they
wanted
> > > > their table files stored within. The reason for this is that as a
> > > > single-exe application I want whatever user logs onto the system and
> > starts
> > > > the app to be able to create and/or load up their own table
> > files...although
> > > > they will ALL be defined exactly the same way as per the stored
> > Definitions.
> > > > But again, I could not get my app to startup and create a table
unless I
> > > > actually hard-coded it's alias path into the component property at
> > > > design-time. Nothing would hook up if I merely did it in code as I
> > wanted.
> > > > How is this properly accomplished? And then how do I manage it so
that
> > each
> > > > user can name his or her table files as wanted as well as have them
> > created
> > > > in the directory of their choice?
> > >
> > > I'm afraid I don't follow this. Are you saying you have a single-user
> > > embedded server app, but you don't know how to set the database path
at
> > > runtime?
> > >
> > > --
> > > David Marcus
> >
> >
>
>