Associations SQLCetal DataContext non générées

Question

Je génère les classes DataContext LINQ-to-SQL et entité pour une base de données. La base de données comporte plusieurs tables, dont deux sont [AccountMaster] et [AccountCodes]. Une relation de clé étrangère est définie entre eux, avec [AccountMaster] .AccountNumber étant référencé à partir de [AccountCodes]. L'ajout d'un fichier LINQ-to-SQL dans VS2008 et le fait de faire glisser ces tables dans la vue de conception DBML génère de manière appropriée une collection de AccountNotes dans la classe AccountMaster.

Pendant ce temps, l'utilisation de SQLMetal pour générer le DataContext ne produit aucune collection EntitySet.

sortie Concepteur:

[Table(Name="dbo.A01_AccountMaster")] 
public partial class A01_AccountMaster //... 
{ 
//... 
    private long _AccountNumber; 
    private EntitySet<A01aAccountNote> _A01aAccountNotes; 
//... 
} 

sortie SQLMetal:

[Table(Name="dbo.A01_AccountMaster")] 
[DataContract()] 
public partial class A01_AccountMaster //... 
{ 
//... 
    private long _AccountNumber; 
//... 
} 

Je suivais le guide à

http://weblogs.asp.net/scottgu/archive/2007/07/11/linq-to-sql-part-4-updating-our-database.aspx

J'ai essayé d'abord générer le fichier DBML en utilisant SQLMetal , puis générer le fichier DataContext.cs à partir du DBML résultant:

sqlmetal.exe /server:srv /database:db /user:usr /password:pwd /sprocs /namespace:AccountContext /context:AccountContext /dbml:AccountContext.dbml /language:csharp /serialization:unidirectional 
sqlmetal.exe /sprocs /namespace:AccountContext /context:AccountContext /code:AccountContext.cs /language:csharp /serialization:unidirectional AccountContext.dbml 

Cela ne génère pas les associations. En fait, l'inspection des fichiers DBML de SQLMetal par rapport à la vue Concepteur:

Création DBML:

<Type Name="A01_AccountMaster"> 
<!-- ... --> 
<Column Name="AccountNumber" Type="System.Int64" DbType="BigInt NOT NULL" CanBeNull="false" /> 
<Association Name="A01_AccountMaster_A01aAccountNote" Member="A01aAccountNotes" ThisKey="AccountNumber" OtherKey="AccountNumber" Type="A01aAccountNote" /> 
<!-- ... --> 
</Type> 

SQLMetal DBML:

<Type Name="A01_AccountMaster"> 
<!-- ... --> 
<Column Name="AccountNumber" Type="System.Int64" DbType="BigInt NOT NULL" CanBeNull="false" /> 
<!-- ... --> 
</Type> 

Ainsi, l'association manque déjà à l'étape DBML .

Étant donné que la base de données contient des tonnes de tables/sprocs, il n'est pas pratique d'utiliser le concepteur pour régénérer les classes DataContext. Comment faire pour que SQLMetal génère des associations correctement?

EDIT:

Exécution SQLMetal sur la base de données entière, je réalise que certaines associations d'entités sont générées correctement. La clé étrangère sur AccountNotes est définie comme:

ALTER TABLE [dbo].[A01aAccountNotes] WITH CHECK ADD CONSTRAINT [FK_A01aAccountNotes_A01_AccountMaster] FOREIGN KEY([AccountNumber]) 
REFERENCES [dbo].[A01_AccountMaster] ([AccountNumber]) 
GO 

ALTER TABLE [dbo].[A01aAccountNotes] CHECK CONSTRAINT [FK_A01aAccountNotes_A01_AccountMaster] 
GO 

EDIT2:

J'ai remarqué que les associations créées correctement sont celles qui ont une règle ON SUPPRIMER CASCADE/UPDATE. Est-il alors absurde de générer des associations qui n'ont pas cette règle strictement définie au niveau de la base de données?

Answer 1

Cela ressemble soit à un bogue dans SQLMetal, soit à une incohérence dans la base de données.

Vous obtiendrez différents résultats d'extraction car il s'agit de deux bases de code différentes (ne demandez pas). Une chose que vous pouvez faire est d'activer le traçage SQL pour observer les commandes DDQL TSQL que SqlMetal envoie à la base de données pour récupérer la liste. Ils sont une combinaison de requêtes INFORMATION_SCHEMA avec diverses jointures.

Cela ressemble à une partie de la jointure requise pour voir les associations est ratée. Si vous copiez les requêtes envoyées à SQL Server dans une fenêtre SQL Management Studio et les exécutez, vous verrez probablement les associations manquantes. Une fois que vous avez confirmé que c'est le cas, vous pouvez essayer de transformer certaines jointures en jointures GAUCHE pour voir quelle pièce est défaillante (ou supprimer certains critères WHERE). À un certain moment, la requête retournera les associations.

Vous pouvez alors être en mesure de modifier le schéma de sorte qu'il fonctionne (la source de SQLMetal n'est pas disponible :()

Answer 2

Nous avons eu un problème similaire où une table avait un indice redondant qui a été défini comme unique, , index non clusterisé sur la colonne qui est la clé primaire de tables qui est déjà l'index clusterisé Lorsque nous avons essayé de supprimer l'index non cluster, SQL Server a résisté car il y avait des clés étrangères selon lui. clés étrangères, supprimer l'index, recréer les clés étrangères (maintenant en fonction de la PK réelle), puis SQL Metal était heureux