As far as adding and editing records goes this is a standard approach that
still applies. Where some differences occur is how you select records.

For example, if you are inserting a record, you may not care what data is in
the table already. You just know you need to add a record. With native IBO
controls is all you have to do is prepare a datset (without even opening it)
and call the Insert method which will allow you to type in values to the
controls. Then hit post and the record will be sent to the server. You
didn't even have to open the query.

As far as editing goes, typically a user has to do something to locate the
record to edit. Using PDOX apps, the users often had a monstrous spreadsheet
of records the eye had to sift through, then they would scroll the record
pointer to the record of interest and proceed to modify it. With native IBO
is all you have to do is call the Search method and the controls go into
what I call search mode. Then, you can type in search criteria using various
formats which are simple and quite extensive. Then, if the record of
interest exists just that record will come back from the server for the user
to manipulate. This saves a lot of strain on the network because you are
only bringing back the record of interest and you are saving the user's eyes
a lot of strain because they don't have to sift through so many records.

These are two of the greatest benefits that the client/server architecture
brings you as an application developer. This is just the start too.

Art recommended getting the Getting Started Guide. I heartily second that
opinion. He also suggested that you consider using ClientDatasets. I
strongly discourage this suggestion. With IBO there is absolutely no need to
use client datasets at all. I have a very good handle on transaction
processing so that my datasets act just like a separate in-memory container
once all the records have been fetched. No need at all to add that extra
clumsy layer into you applications.

Here's the rule of thumb with IBO. If you are having to do some clumsy
coding and adding an uncomfortable amount of fat in your client there is
something missing in your understanding of IBO and you need to come to this
list and have us review your approach to make suggestions concerning it.

Using client datasets is excellent advice if you are using IBX because its
transaction handling is so primitive and immature but it is a horrible and
unnecessary amount of work if you are using IBO.

HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: <SLSolutions@...>
To: <IBObjects@egroups.com>
Sent: Monday, January 08, 2001 11:40 AM
Subject: [IBO] An example - please


> Hello:
>
> I am a total beginner at Interbase and IBO. I am converting
> Delphi5/Paradox applications to Delphi5/IBO/IB6. In reading the
> posts, I can see that I have a Paradox mindset. I have been trying,
> with no luck, to find a book on using Delphi/Interbase but until I
> do, I want to get off on the right foot. If someone could give me a
> basic example of how to properly code this using Interbase:
>
> Assume a basic file maintenance form where user can add, modify,
> delete records. I realize I could user a navigation bar and allow it
> to handle the adds, mods, delete, etc but for learning purposes, I
> would like to handle this myself.
>
> On my form I have 4 buttons. Add, Modify, Save, Cancel. I also have
> numerious DBEdits linked to the various fields in my table. In my
> Paradox verison my database logic is as follows:
>
> Add Button:
> Append;
>
> Modify Button:
> Edit;
>
> Save Button:
> Post;
>
> Cancel Button:
> Cancel:
>
> The user presses the Add Button, enters data in the DBEdits, then
> either presses the Save or Cancel buttons. I can see my reading the
> posts that this IS NOT the way it should be handled with Interbase.
>
> Assuming the above form, how should the add be handled? When the
> user presses the Add Button, if I don't Append, what do I do?
>
> Any example would be greatly appriciated.
>
> Thanks.