| Subject | Re: [IBO] IBO Help files? |
|---|---|
| Author | Helen Borrie |
| Post date | 2001-07-18T02:24:38Z |
At 05:28 PM 17-07-01 -0600, Gordon Hamm wrote:
Your client app gets that information from the database, via the structure that is returned to it by way of the gds32 client layer when the statement is prepared. But the client cannot get things like the internal workings of SPs or triggers. So IBO provides you with a great deal of client-side handling to get around that fact.
Forgetting the client for a moment, on the server triggers fire AFTER the row has passed to the server, but before the work is finally committed to the server. The trigger will fire; but if the transaction fails for some reason, all the processing inside that transaction will be reversed. This condition will occur if you pass NULL (or a duplicate value) across the wire for a PK, for example.
Coming back to the client app, if you set up GeneratorLinks for these generated PK columns, IBO will get the new value just before the dataset goes into Insert state and you will have nothing further to do.
If you *want* to have a trigger populate this column, then you can make a property setting to have the non-nullable column ignored when the component checks for Required columns. In your case, I would not recommend trying to go in this direction before you get your head around how InterBase works, nor even when you do! This is NOT desktop computing!
A proper trigger that tests for NOT NULL won't ever generate a value when row maintenance is done from an application that implements GeneratorLinks. But IMO, you should have a trigger for a generated PK regardless of the smarts provided by the application because someone somewhere sometime is going to want to maintain data interactively using some utility tool.
On the subject of the Help, your point about documentation is taken - you (or someone else) said you have to know what you are looking for first. This is a characteristic of the assumptions about users of these components as much as anything. They are designed to encapsulate a lot of the capability of the database - which they do in overwhelming volume. However, it's undeniable that, if you come into it not understanding the capability of the database or the inheritance model of Delphi, you are bound to get into deep water pretty fast.
It is not the role of IBO to teach you the basics of client/server computing. Why, not even the official InterBase manuals do a particularly good job of that! IOW, you have unrealistic expectations if you want IBO to teach you the fundamentals of InterBase. About client/server computing you will learn a great deal, nevertheless, by practising with the samples.
A similar point has to be made about Delphi/C++B and object-oriented programming. If you are using the IBO TDataset descendants (TIBO prefix) the help text for those is in the Delphi VCL Help. In the IBO Component help, you will find documentation for the stuff in the underlying InternalDataset, which is a wrapping TIB_BDataset surfaced as a property of the the TIBO* components. Some of the properties of the InternalDataset are surfaced to the ObjectInspector for them - such as KeyLinks and GeneratorLinks - but others need to be accessed via this underlying object using run-time handlers.
When "down there" in the help for the InternalDataset, it's important to use the 'Hierarchy' button on the helpfile toolbar to work your way back through the hierarchy to the place where the properties, methods and events of the ancestors are most fully documented. In general, Jason has the fullest documentation at the first level where a custom class is implemented. In the case of TIB_Statement and its descendants, documentation occurs at several lower levels because this is the real foundation stuff of IBO.
There are several megabytes of component documentation in the help file. There are tech info sheets on the web site. There is an FAQ section on the web site.
The Getting Started Guide (GSG) tried to address the problems encountered by newcomers to IBO. For users of TIBO*, it doesn't duplicate the Delphi VCL help at all - it's assumed you are able to access that. It deals with the native data access features and, later, provides example of using the native controls - so that part is not applicable to TIBO*. For all new users of IBO, I think it does help you up that bell curve if you already understand how the database works and how Delphi inheritance works.
To help you get into InterBase/Firebird I do urge you to join the ib-support list at http://www.yahoogroups.com/group/ib-support and, of course, keep firing your IBO questions here.
Regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
>thanks, that worked.. I sort of get it I think, Im putting the control inThe server requires the column to have a value because it is declared as NOT NULL. Whether a trigger has been set or not is immaterial.
>insert mode, but the server is requiring a the field to have a value, but it
>doesnt cuz the trigger hasnt been set? I am assuming this wouldnt be an
>issue if I were to issue a SQL insert statement? In otherwords, this is a
>BDE design thing..
Your client app gets that information from the database, via the structure that is returned to it by way of the gds32 client layer when the statement is prepared. But the client cannot get things like the internal workings of SPs or triggers. So IBO provides you with a great deal of client-side handling to get around that fact.
Forgetting the client for a moment, on the server triggers fire AFTER the row has passed to the server, but before the work is finally committed to the server. The trigger will fire; but if the transaction fails for some reason, all the processing inside that transaction will be reversed. This condition will occur if you pass NULL (or a duplicate value) across the wire for a PK, for example.
Coming back to the client app, if you set up GeneratorLinks for these generated PK columns, IBO will get the new value just before the dataset goes into Insert state and you will have nothing further to do.
If you *want* to have a trigger populate this column, then you can make a property setting to have the non-nullable column ignored when the component checks for Required columns. In your case, I would not recommend trying to go in this direction before you get your head around how InterBase works, nor even when you do! This is NOT desktop computing!
A proper trigger that tests for NOT NULL won't ever generate a value when row maintenance is done from an application that implements GeneratorLinks. But IMO, you should have a trigger for a generated PK regardless of the smarts provided by the application because someone somewhere sometime is going to want to maintain data interactively using some utility tool.
On the subject of the Help, your point about documentation is taken - you (or someone else) said you have to know what you are looking for first. This is a characteristic of the assumptions about users of these components as much as anything. They are designed to encapsulate a lot of the capability of the database - which they do in overwhelming volume. However, it's undeniable that, if you come into it not understanding the capability of the database or the inheritance model of Delphi, you are bound to get into deep water pretty fast.
It is not the role of IBO to teach you the basics of client/server computing. Why, not even the official InterBase manuals do a particularly good job of that! IOW, you have unrealistic expectations if you want IBO to teach you the fundamentals of InterBase. About client/server computing you will learn a great deal, nevertheless, by practising with the samples.
A similar point has to be made about Delphi/C++B and object-oriented programming. If you are using the IBO TDataset descendants (TIBO prefix) the help text for those is in the Delphi VCL Help. In the IBO Component help, you will find documentation for the stuff in the underlying InternalDataset, which is a wrapping TIB_BDataset surfaced as a property of the the TIBO* components. Some of the properties of the InternalDataset are surfaced to the ObjectInspector for them - such as KeyLinks and GeneratorLinks - but others need to be accessed via this underlying object using run-time handlers.
When "down there" in the help for the InternalDataset, it's important to use the 'Hierarchy' button on the helpfile toolbar to work your way back through the hierarchy to the place where the properties, methods and events of the ancestors are most fully documented. In general, Jason has the fullest documentation at the first level where a custom class is implemented. In the case of TIB_Statement and its descendants, documentation occurs at several lower levels because this is the real foundation stuff of IBO.
There are several megabytes of component documentation in the help file. There are tech info sheets on the web site. There is an FAQ section on the web site.
The Getting Started Guide (GSG) tried to address the problems encountered by newcomers to IBO. For users of TIBO*, it doesn't duplicate the Delphi VCL help at all - it's assumed you are able to access that. It deals with the native data access features and, later, provides example of using the native controls - so that part is not applicable to TIBO*. For all new users of IBO, I think it does help you up that bell curve if you already understand how the database works and how Delphi inheritance works.
To help you get into InterBase/Firebird I do urge you to join the ib-support list at http://www.yahoogroups.com/group/ib-support and, of course, keep firing your IBO questions here.
Regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________