EDIT:
Ma réponse initiale était erronée parce qu'elle était fondée sur un malentendu au sujet du schéma de la table de journal. Compte tenu de la publication ultérieure par Sheetal de ce schéma (et je me suis rendu compte que le nom de la colonne était UserLogId, pas UserLoginID ...) cette hypothèse est invalidée.
La table de journal est donc
CREATE TABLE USERLOG
(UserLogId int identity (1,1) CONSTRAINT pk_UserLogId primary key,
UserName nvarchar(50) not null,
LogInTime datetime CONSTRAINT dft_LogInTime default getdate()
)
--ADDING LOGOUT TIME ALTER TABLE USERLOG ADD LogOutTime datetime
faisant la question OP plus déroutante ...
Comment peut-on obtenir des conditions de violation PK avec une colonne d'identité? (à moins que le paramètre INDENTITY_INSERT pour cette table, et que les modifications/insertions manuelles qui incluent une valeur pour la colonne PK, peut-être Sheetal peut faire la lumière sur ce ...?)
Sheetal devrait donc se pencher sur la logique de l'application , dans la zone du code qui termine la connexion, après l'authentification de l'utilisateur, et recherche par exemple des requêtes où une valeur est spécifiée pour la colonne UserLogId (autre que dans les clauses WHERE, bien sûr).
BTW, je ne suis pas sûr pourquoi nous essayons tous si dur? donné un minimum d'effort propre de Sheetal avec cadrage à ses questions, même si l'on considère un handicap possible avec la langue anglaise, et de fournir des informations ... et certainement son taux d'acceptation ... ;-)
- ce qui suit est faux (basé sur une mauvaise hypothèse) ----
Le problème semble être que le UserLoginId est déclaré en tant que clé primaire pour la table de journal. C'est un choix étrange pour une telle table parce que nous nous attendrions à avoir beaucoup d'enregistrements de journal pour un utilisateur donné.
Dans une table SQL, la contrainte de clé primaire indique essentiellement à SQL de refuser toute requête INSERT pour des enregistrements avec une valeur de clé primaire qui existe déjà dans la table. (Et pour renvoyer une condition d'erreur similaire à celle mentionnée dans la question)
Il est difficile de ne pas connaître le schéma de la table de journal et le cas d'utilisation, mais vous pouvez peut-être supprimer la contrainte pk ou utiliser une autre colonne pour cela. Une colonne auto-incrémentée appelée "EventId" pourrait être un bon choix pour cela. Vous obtiendrez quelque chose comme ça dans la table de journal:
EventID (PK) DateTime UserLoginId EventType Details
1 01/02/2008 06:15:01 172 LogIn Stan
2 01/02/2008 06:15:21 321 LogIn Jeff
3 01/02/2008 06:15:24 172 FileDownload Report7.pdf
4 01/02/2008 06:15:54 172 FileDownload SalesTraining.pdf
5 01/02/2008 06:17:21 321 LogOut
etc ...
Pouvez-vous fournir une définition de table? Quel type de données utilisez-vous dans la colonne principale? Avez-vous utilisé IDENTITY? –
@Sheetal: Je ne comprends pas ce que vous entendez par définir la valeur maximale de la colonne d'identité. La colonne d'identité requiert une nouvelle valeur chaque fois que vous l'insérez. Été un moment depuis que j'ai fait SQL Server, mais je pense que l'insertion de null ou en laissant la valeur hors de l'instruction d'insertion devrait provoquer l'incrémentation automatique de la valeur. Peut-être que quelqu'un avec une expérience récente de SQL Server peut valider. –
Telle est la définition de la table CREATE TABLE USERLOG ( UserLogId identité int (1,1) CONTRAINTE pk_UserLogId clé primaire, UserName nvarchar (50) non nul, LogInTime datetime CONTRAINTE dft_LogInTime défaut getdate() ) - ADDING LOGOUT TIME ALTER TABLE USERLOG AJOUTER LogOutTime datetime – Sheetal