At 06:50 PM 11/09/2004 +1000, you wrote:

> I'm using Marathon (I didn't realize Delphi was in the background) for
> the purposes of setting up the tables and all table related stuff
> (relationships etc .....oh and training). Once set up, I'm looking at
> either VB or RealBasic as a frontend using ODBC. I'm not familiar with
> the Delphi way of doing things. I can't check just yet, but are you
> saying that in order to retrieve the next unique number it's just a
> matter of issuing a 'select' statement in the form you mentioned above.

In your own applications, yes. But not in the tools, as a rule.

> I hate to appear stupid, I'm just trying to make sure that this is not a
> Delphi only type scenario.

It happens because of the way you are going about the task of inserting
data. Delphi (like most other encapsulated data access interfaces) will
either take care of non-nullable columns and throw a client-side exception
when you throw null at such a column; the more "raw" interfaces will
accept anything and wait for the server to throw the exception.

I haven't used Marathon for ages; but don't use a "show tables" type of
interface for populating tables. Use a "DSQL" window and set up a
parameterised query, of this form (assuming here that col1 is your primary
key column):

insert into aTable (col2, col2, col3)
values (:col1, :col2, :col3)

Click the Prepare button and go to the Params tab. AFAIR, you see a list
of params. Type the values you want into each param and hit the Execute
button.

Then, go back and enter the next set of param values and hit Execute.

Carry on like this until you've done a few, and hit the Commit button at
some point..

The statement will stay prepared after the commit (unless you unprepare it)
and you can continue to insert bunches of rows in like manner, until you're
done.

By this method, you're allowing the generator and the trigger to do their
work without any kind of workaround.

./heLen