0

J'ai des données existantes dans ma table Étudiant. Maintenant, je veux ajouter la clé étrangère. Lorsque j'essaie d'ajouter la clé étrangère avec des données existantes, elle donne une erreur "L'instruction ALTER TABLE est en conflit avec la contrainte FOREIGN KEY". Si je supprime toutes les données de la table Étudiant alors il ajoute la clé étrangère avec succès. Maintenant, je veux ajouter une clé étrangère sans perdre les données sur le serveur distant. Comment puis-je le faire? J'ai vu diverses réponses mais je n'ai pas trouvé la solution.Ajouter une clé étrangère dans ma table lorsque j'ai des données existantes dans ma table sur le serveur distant?

Table des élèves (Voir deux propriétés)

public int Id { get; set; } 

    [Required] 
    [StringLength(30)] 
    [RegularExpression(@"^[A-Za-z\s]{1,}[\.]{0,1}[A-Za-z\s]{0,}$", 
    ErrorMessage = "Invalid name. Use letters only")] 
    public string Name { get; set; } 

    [Required] 
    [StringLength(30)] 
    [RegularExpression(@"^[A-Za-z\s]{1,}[\.]{0,1}[A-Za-z\s]{0,}$", 
    ErrorMessage = "Invalid name. Use letters only")] 
    [Display(Name = "Father Name")] 
    public String FatherName { get; set; } 


    [Display(Name = "Student Picture")] 
    public String ImageURL { get; set; } 

    public Class Class { get; set; } 

    [Required] 
    [Display(Name = "Class Title")] 
    public int ClassId { get; set; } 

    [ForeignKey("Account")] 
    public int AccountId { get; set; } 

    public virtual Account Account { get; set; } 

    public string Gender { get; set; } 

    public string Status { get; set; } = "Active"; 

    [Required] 
    [Range(0, 10000)] 
    public int RegistrationFee { get; set; } 

    public int InstalmentId { get; set; } 

    public virtual Instalment Instalment { get; set; } 
    } 

Voici ma table Acomptes qui Id je veux faire FK en étudiant

public int Id { get; set; } 

    [Required] 
    public int Instalment1 { get; set; } 

    [Required] 
    public DateTime Date1 { get; set; } 

    public int Instalment2 { get; set; } 

    public DateTime Date2 { get; set; } 

    public int Instalment3 { get; set; } 

    public DateTime Date3 { get; set; } 

    public int Instalment4 { get; set; } 

    public DateTime Date4 { get; set; } 
} 

Je veux la solution simple pour parce qu'à l'avenir il y aura beaucoup de situations où je changerais la base de données en conséquence. Merci!

+1

Veuillez afficher le schéma de table des deux tables. – Eli

Répondre

2

Comme vous avez des données existantes, le FK doit être nullable. Le FK doit donc être de type int?. Si cela ne convient pas à votre logique métier, vous devez sélectionner un étudiant par défaut et modifier le fichier migration.cs correspondant avant d'appliquer la mise à jour à la base de données. Imho, la solution Null est la meilleure dans votre cas: adaptez votre logique métier pour vivre avec des données héritées.

+0

Oui, vous avez raison! Tu m'as donné la solution. Mais comment pouvons-nous le résoudre? Et si nous voulons le rendre non-nul? –

+0

Vous pouvez le rendre nullable, remplir chaque enregistrement avec un FK valide, puis vous pouvez modifier la table pour le rendre non-nullable. – Eli

+0

@Eli Exactement. Tu as raison. –

2

Fondamentalement, vous devez trouver quels enregistrements sont en conflit: c'est là que vous voulez appliquer une clé étrangère, mais la contrainte n'est pas respectée.

Ensuite, corrigez ce qui est incorrectement défini en ajoutant les données manquantes ou en corrigeant les données existantes.

Ensuite, vous pourrez ajouter la clé étrangère à la table.

Par exemple:

Si JOBID de champ dans la table de personne est une clé étrangère de la table JOBS, et vous avez un enregistrement de la table PERSONNE avec JOBID 53 et 53 n'existe pas dans le tableau EMPLOIS vous ne sera pas en mesure d'exécuter la table de modification pour ajouter la contrainte de clé de l'étranger.

Vous devez d'abord ajouter un travail avec l'ID 53 à la table JOBS, ou si le travail est réellement présent mais avec un ID différent, corrigez le jobId dans la table PERSON. J'espère que cela clarifie votre doute.