| Subject | Re: [firebird-support] Re: Server defaults - what are they? |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-11-26T03:40:18Z |
At 02:51 AM 26/11/2005 +0000, you wrote:
client/server systems. On the server side, you have real, i.e. stored,
data which is there to be retrieved by the client application. It can be
accessed by any sort of client application, not just IBO.
On the client side, you have "cooked" data that IBO (like other OO
development environments) turns into object instances of the various
classes that your application works on. Simply put, 2 sides: server side
and client side.
In IBO, you can define a myriad of attributes ("properties") for these data
access objects, including default values for columns that are entirely
client-assigned. These defaults are stored persistently in the
DefaultValues properties of the connection and/or statement
objects. However, IBO also gives you the option of fetching the defaults
from the server side, to avoid defining your own on the client
side. Hence, the term "Server Defaults" is talking about that, as distinct
from your own, developer-assigned defaults.
too. This is a slice of bread with honey on one side and live bees on the
other.
On the one hand, client-assigned defaults will override the server-side
definitions. This may or may not be what the original database designer
intended, since defining defaults is generally done to oblige some business
rule in a consistent fashion.
On the other, automating use of the server defaults adds to the time it
takes the app to make its initial connection and show its face to the
user. Since the API doesn't have any provision to fetch column defaults
across the wire in the XSQLDA structure when a statement is prepared, there
is some noisy querying of the system tables to do at connection time to
fetch these defaults across and store them in the DefaultValues structures
of the client application.
It's optional, and rightly so. It's elegant from the POV of ensuring that
the application won't break the business rules, but it tends to aggravate a
problem that's already there for ex-desktop programmers who haven't yet
caught up with the concept of "data on demand" and open 200 tables when the
main form starts up. (See the daily ration of "Firebird slooooow to
connect" threads we see here....)
./heLen
>Adam,Hmm, that's a bit different. IBO is for writing client applications for
>
>Thanks for taking the time for the tutorial and for
>the ALTER TABLE "gotcha"...
>
>My "query" has been very nicely taken care of by your
>reply and by luc's.
>
>I encountered the term "server defaults" in another
>list (IBO)
client/server systems. On the server side, you have real, i.e. stored,
data which is there to be retrieved by the client application. It can be
accessed by any sort of client application, not just IBO.
On the client side, you have "cooked" data that IBO (like other OO
development environments) turns into object instances of the various
classes that your application works on. Simply put, 2 sides: server side
and client side.
In IBO, you can define a myriad of attributes ("properties") for these data
access objects, including default values for columns that are entirely
client-assigned. These defaults are stored persistently in the
DefaultValues properties of the connection and/or statement
objects. However, IBO also gives you the option of fetching the defaults
from the server side, to avoid defining your own on the client
side. Hence, the term "Server Defaults" is talking about that, as distinct
from your own, developer-assigned defaults.
>and could find no references for it underSure, but it's important to understand why the distinction is necessary,
>that specific wording. It is evidently an evolution
>or synonym of "default values" and I think I'm all
>set to better understand those other postings (in IBO,
>etc.).
too. This is a slice of bread with honey on one side and live bees on the
other.
On the one hand, client-assigned defaults will override the server-side
definitions. This may or may not be what the original database designer
intended, since defining defaults is generally done to oblige some business
rule in a consistent fashion.
On the other, automating use of the server defaults adds to the time it
takes the app to make its initial connection and show its face to the
user. Since the API doesn't have any provision to fetch column defaults
across the wire in the XSQLDA structure when a statement is prepared, there
is some noisy querying of the system tables to do at connection time to
fetch these defaults across and store them in the DefaultValues structures
of the client application.
It's optional, and rightly so. It's elegant from the POV of ensuring that
the application won't break the business rules, but it tends to aggravate a
problem that's already there for ex-desktop programmers who haven't yet
caught up with the concept of "data on demand" and open 200 tables when the
main form starts up. (See the daily ration of "Firebird slooooow to
connect" threads we see here....)
./heLen