Strongly typed table missing "FindBy..." method

[mjf]

I created strongly typed dataset objects by configuring data adapters
using the VS.2003 wizard. All the tables have primary keys; some have
multi-column primary keys.

Some of the tables have FindBy... methods, such as FindByValue_name
(where Value_name is the name of the primary key field), or
FindByWO_numEntity_id (where WO_num and Entity_id are the field names
that make up the primary key for the table). Other tables do not have
any FindBy... method, even though the tables do in fact have primary
keys in SQL Server.

Working backwards, I go to the .xsd for the dataset I use to access
these tables. Sure enough, the tables without FindBy... methods aren't
shown as having primary keys in the .xsd.

As I said, I created the dataset by configuring data adapters for each
table, then generating the dataset by right-clicking on one of the
adapters and choosing Generate Dataset, and then including all the
adapters in the dataset. So, why do some of the tables in the .xsd
have primary keys (and FindBy... methods) while others do not?

Here's some data that may help. The tables that are shown in the .xsd
as having primary keys are generated with fairly simple SQL SELECT
statements: SELECT tbl.a, tbl.b FROM tbl WHERE tbl.b = 1

The tables that are shown in the .xsd as *not* having primary keys (and
don't have FindBy... methods in their respective tables) are generated
with SQL SELECT statements that do inner joins. Now, for table T, for
example, the SELECT includes every field for table T. Does VS somehow
decide that if a table is retrieved as a result of a join, it cannot
have a primary key?

Thanks in advance.

 

[Miha Markic [MVP C#]]

The tables that are shown in the .xsd as *not* having primary keys (and
don't have FindBy... methods in their respective tables) are generated
with SQL SELECT statements that do inner joins. Now, for table T, for
example, the SELECT includes every field for table T. Does VS somehow
decide that if a table is retrieved as a result of a join, it cannot
have a primary key?

Yes.

 

[mjf]

Miha, thanks for the info. What's the reasoning behind that?

The tables that are shown in the .xsd as *not* having primary keys (and
don't have FindBy... methods in their respective tables) are generated
with SQL SELECT statements that do inner joins. Now, for table T, for
example, the SELECT includes every field for table T. Does VS somehow
decide that if a table is retrieved as a result of a join, it cannot
have a primary key?

Yes.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

 

[Miha Markic [MVP C#]]

The Visual Studio generator isn't exactly too complex ;-)
As another option you might use CodeSmith in combination with a proper
template, such as:
http://www.rthand.com/DesktopModule...alias=RightHand&lang=en-US&ItemID=6&mid=10244

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

Miha, thanks for the info. What's the reasoning behind that?

The tables that are shown in the .xsd as *not* having primary keys (and
don't have FindBy... methods in their respective tables) are generated
with SQL SELECT statements that do inner joins. Now, for table T, for
example, the SELECT includes every field for table T. Does VS somehow
decide that if a table is retrieved as a result of a join, it cannot
have a primary key?

Yes.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info