At 06:51 AM 19-06-01 +0100, you wrote:

>Hi ! Sorry to be so basic but I need help !
>I have a relation called 'bookings' into which I want to insert a brand new record, using a form full of ib_controls, tib_edits, date_time picker, ib_lookupcombo etc.
>
>I have a Tib_connection, a Tib_transaction, and Tib_Query and a tib_datasource. (all on a datamodule).
>
>Question1.
>I make the connection, start the transaction, open the query ..
>But what should the query sql be ? 'Select * from bookings' with no where clause ?
>This seems to work fine but at present I have an empty table and a single development computer.
>Will 'select * from bookings' bring the whole blooming table down the network when I move to a network ?

Yes, it will. You will need to collect parameters from your user to restrict the set that is brought over to the client. From your later description of the Bookings structure, SELECT * is not a good thing, either. SELECT <columnlist> is always preferable.

>Or should I use 'Insert into Bookings' and if so will the tib_Controls operate properly.

A SELECT statement selects. You form datasets with SELECTs. An INSERT statement inserts. When you call the dataset's Insert method, IBO will form an INSERT statement for you internally from the structure of the selected dataset, unless you happen to need something special in the statement.- in which case, you can supply your own via the InsertSQL property. Similar happens for updates (EditSQL) and deletes (DeleteSQL). This is, after all, object-oriented programming!!! You must be spot-on with your KeyLinks, as well.

>[Obviously I want to use the same form for recall and edit of data if possible]
>Should I rather use a tib_cursor or dsql or stored procedure ??

You would not normally use a cursor for a dataset that the user is going to browse, search, etc., because a cursor is unidirectional. A "selectable" stored procedure is sometimes useful for forming unusual datasets. An executable stored procedure with input parameters can be used to perform DML (inserts, edits, deletes) - that call can go into the xxxxSQL properties of the dataset if you need to do that.

>Question 2.
>The Bookings record is rather 'wide'. It is partly concerned with dates and times and places, and partly with money, credit card numbers etc. I want to use two forms, a seperate form for each aspect.
>So can I
>Make connection, Start transaction, Show the dates etc form and fill in the potential record from that then
>hide the dates form and show the money form and fill in the rest of the record from that, then close the transaction? Or will hiding the form lose the buffered data ?

With client/server data access you are never physically touching the data. You can look at the same rows through multiple datasets - if the queries are all inside the same transaction, you can update different parts of the same row through different queries.

> (note that there is much for the client to do between the dates and the cash and there may be a gap of about 20 minutes between one and the other).

It's up to you whether you do this on multiple forms or all on one form. If there is a time lag between initial data entry and finalising a booking, then you will want to commit the initial stuff and let the user come back for the rest.

>Or would it be better to close the first form and comit the transaction then show the second form, selecting the part-completed record by a 'where bookingnumber = xxxx' clause.

You don't have to have separate forms. You can bring all the columns you need for the whole operation into the one dataset. In a grid just show those columns that the user needs to identify the booking. You can lay out the details in a single-row panel alongside, using various edit controls. As long as the grid and the individual edit controls share the same data source, the details for each grid row will be correct as the user scrolls the grid. You'll need to limit the number of rows brought to the client, e.g. by her personal id, by date (or both).

>(Then if the client found the cash aspect too daunting, I should have to positively delete the already part completed record becuse it was already committed)

Are you saying that a booking should be cancelled if the operator can't manage to do the cash part of the task? A row only needs its non-nullable columns filled in order to exist.

>Or would it be better to split the wide 'booking' record into two parts linked by keys, each filled from its own form. The touble with that being the extra complication and two extra integers to make the key-link.

This all sounds far more complicated than it is.

>Sorry to pick your brains like this. Is there somewhere where I could really find out about it all (other than the Help and Examples with ibobjects)

It sounds as if you need to keep asking questions AND study the examples. The Help provides information about using the components but it won't teach you how to design your user interface. There are third-party books available on designing user interfaces. You can also learn a lot from talking to your users on this subject. <g>

Regards,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________