Add mode problem on field setup with Foreign Key

Hello,

I have two tables (one-to-many relation) related thru a common key. I have setup the Relation using the Database Designer. The Form is populated using Drag-and-drop which automatically adds the BindingSource, TableAdapter, and Binding Navigator. The Relation works great in the change mode, and life is good.

In the Add mode the field setup with the Foreign Key is not automatically populated as it is in Change mode. The field can be updated manually, but that defeats the purpose of setting up the Relation.

Any ideas how to fix this?

I know this is difficult to visualize without seeing it.

Thank you for any ideas,

Tom

The detail grid (or some other graphic control) should be linked to the relation itself not the underlying detail database table. Master's PK should be FK in Detail.

See here on MSDN2:

One BindingSource is bound to the parent Customers table in the data set. This data is displayed in the master DataGridView control. The other BindingSource is bound to the first data connector. The DataMember property of the second BindingSource is set to the DataRelation name. This causes the associated detail DataGridView control to display the rows of the child Orders table that correspond to the current row in the master DataGridView control.

Add a second databse - benefits?

Hi, there is an existing application running on a SQL Server database.

Now I have to built a different app, which will have two common tables
with the existing database (Customers, sales)

Is there any benefit (performance mainly) creating the tables for the
new app in a new database? (On the same machine and the same instance)

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!chora (choracy@.hotmail.com) writes:
> Hi, there is an existing application running on a SQL Server database.
> Now I have to built a different app, which will have two common tables
> with the existing database (Customers, sales)
> Is there any benefit (performance mainly) creating the tables for the
> new app in a new database? (On the same machine and the same instance)

There is too little information to say anything with certainty. If the
two apps not only share the table definitions, but also the data in
the table, putting everything in the same database.

As long as the applications are access their individual tables, there
is not much interferance between them. All I can think is that autogrow
caused by one app will affect the userss of the other app two, but
autogrows should not occur frequently.

Of course, in the common tables there may be blocking issues with
improper application design.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||
Erland ,

thanks for the reply.

The databases will share the data of the two tables. The new database
will have 'read only' access to these tables.

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!|||Hi

If these tables are large, then you may want to make them federated and
create a partitioned view for them. This may give you a performance
improvement e.g http://vyaskn.tripod.com/federated.htm

There may also be other reasons to use a separate database such as ownership
(e.g if a third party package it may invalidate the waranty to stick extra
tables in there), security and maintainance.

John

"chora" <choracy@.hotmail.com> wrote in message
news:40d5962f$0$16472$c397aba@.news.newsgroups.ws.. .
>
> Hi, there is an existing application running on a SQL Server database.
> Now I have to built a different app, which will have two common tables
> with the existing database (Customers, sales)
> Is there any benefit (performance mainly) creating the tables for the
> new app in a new database? (On the same machine and the same instance)
>
>
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it!