Hi David.....
Your Solution 1 seems a good idea, it's a bit of a "hack" but you got
me thinking that this could work well. Maybe I could use the time
as another identifer.......I'll give it a try on the test server.
Your other solution I will look into.....not quite sure of a recordset,
will look into this though, if it's more preferred robust method.
thanx again..Carl.
"David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns9685CFE1DFE92dfentonbwaynetinvali@24.168.1 28.74...[color=blue]
> "Larry Linson" <bouncer@localhost.not> wrote in
> news:ZB_we.24799$Ff6.8496@trnddc09:
>[color=green]
>> "Carl" wrote
>>
>> First, unless you have beaucoup data fields that you didn't list,
>> why would you want to have these two tables with a one-to-one
>> relationship? Obviously the simplest, easiest solution is to
>> include all the information in a single table and you don't have
>> to worry about matching keys.
>>[color=darkred]
>> > I could INSERT into TableAccounts first,
>> > which would auto-create the ID, but
>> > how do I use the ID in the second SQL
>> > INSERT on TableMembers ???[/color]
>>
>> Retrieve the record you just entered*, and create the INSERT SQL
>> with code, using that value for the key field just as you use
>> values for any other field.
>>
>> * this may not be as easy as it seems, which
>> may be a good argument, in some cases, for
>> using a "natural key" rather than using AutoNumber
>> as a surrogate key.[/color]
>
> Basically, I agree with Larry's reservations about the data
> structure. However, I've had applications where I needed to break
> down single tables into 1:1 sub-tables because the application
> needed what amounted to record subtypes.
>
> There are two basic ways to do this.
>
> 1. have a field in main side of the 1:1 join that has only one
> purpose, to hold a value that tells you "this record is being
> inserted right now." You'd put something like -10000000 in it during
> the insert, then use that value to identify the single record you've
> just added so you can select its PK value to insert into the second
> table. After you populate the second table, you set this special
> field in the first table to Null. The problem with this approach is
> that it doesn't work well in multi-user applications, unless you
> make the user name part of the ID field you're using to find the
> record that was just inserted.
>
> 2. write VBA code to insert the record in an AppendOnly recordset,
> so you can grab the PK value, then use that to write INSERT SQL to
> insert the record in the second table. You'd probably want to wrap
> this in a transaction to insure that the whole process completes.
> That is, if part of it fails you probably want the whole thing to
> fail.
>
> The 2nd choice is much more complex, but far more robust.
>
> --
> David W. Fenton
http://www.bway.net/~dfenton
> dfenton at bway dot net
http://www.bway.net/~dfassoc[/color]