2009-04-23 8 views
2

J'essaye d'INSÉRER dans une table de base de données SQL, mais cela ne fonctionne pas. J'ai donc utilisé le profileur de serveur SQL pour voir comment il construisait la requête; ce qu'il montre est le suivant:SQL mettant deux guillemets simples autour des champs datetime et ne parvient pas à insérer l'enregistrement

declare @p1 int 
set @p1=0 
declare @p2 int 
set @p2=0 
declare @p3 int 
set @p3=1 
exec InsertProcedureName @[email protected] output, @[email protected] output, 
         @[email protected] output, @ProjectID=N'0', @IPAddress=N'66.229.112.168', 
         @FirstName=N'Mike', @LastName=N'P', @Email=N'[email protected]', 
         @PhoneNumber=N'(254)637-1256', @MobilePhone=NULL, @CurrentAddress=N'', 
         @FromZip=N'10005', @MoveInAddress=N'', @ToZip=N'33067', 
         @MovingSize=N'1', @MovingDate=''2009-04-30 00:00:00:000'', 
           /*  Problem here ^^^ */ 
         @IsMovingVehicle=0, @IsPackingRequired=0, @IncludeInSaveologyPlanner=1 
select @p1, @p2, @p3 

Comme vous pouvez le voir, il met un guillemet deux paires de guillemets simples autour des champs DateHeure, de sorte qu'il produit une erreur de syntaxe dans SQL. Je me demande s'il y a quelque chose que je dois configurer quelque part?

Toute aide serait appréciée.

Voici les détails de l'environnement:

  • Visual Studio 2008
  • .NET 3.5
  • MS SQL Server 2005

Voici le code .NET J'utilise .. ..

//call procedure for results 
strStoredProcedureName = "usp_SMMoverSearchResult_SELECT"; 

Database database = DatabaseFactory.CreateDatabase(); 
DbCommand dbCommand = database.GetStoredProcCommand(strStoredProcedureName); 
dbCommand.CommandTimeout = DataHelper.CONNECTION_TIMEOUT; 

database.AddInParameter(dbCommand, "@MovingDetailID", DbType.String, objPropConsumer.ConsumerMovingDetailID); 
database.AddInParameter(dbCommand, "@FromZip", DbType.String, objPropConsumer.FromZipCode); 
database.AddInParameter(dbCommand, "@ToZip", DbType.String, objPropConsumer.ToZipCode); 
database.AddInParameter(dbCommand, "@MovingDate", DbType.DateTime, objPropConsumer.MoveDate); 
database.AddInParameter(dbCommand, "@PLServiceID", DbType.Int32, objPropConsumer.ServiceID); 
database.AddInParameter(dbCommand, "@FromAreaCode", DbType.String, pFromAreaCode); 
database.AddInParameter(dbCommand, "@FromState", DbType.String, pFromState); 
database.AddInParameter(dbCommand, "@ToAreaCode", DbType.String, pToAreaCode); 
database.AddInParameter(dbCommand, "@ToState", DbType.String, pToState); 

DataSet dstSearchResult = new DataSet("MoverSearchResult"); 
database.LoadDataSet(dbCommand, dstSearchResult, new string[] { "MoverSearchResult" }); 
+0

Pourriez-vous également publier les codes qui génèrent cette requête SQL? Le problème est très apparent (guillemets et deux-points entre secondes et millisecs), donc la racine de votre problème doit être dans le morceau de code qui a généré cette requête. –

+0

poster votre code .net depuis la date à partir de laquelle les informations sont correctes? – Eppz

+0

Pouvez-vous poster le code (ou un exemple qui reproduit le problème) qui construit la requête en premier lieu, mieux de travailler à l'avant qu'à l'arrière. – Lazarus

Répondre

0

Essayez ceci:

'2009-04-30 00:00:00.000' 

Notez les guillemets simples et "." au lieu de ":" pour les millisecondes. Ou essayez ceci:

'2009-04-30 00:00:00' 

Pour vous assurer que ce n'est pas les millisecondes.

+0

J'ai ajouté mon code .NET dans la publication originale. BTW .. J'utilise les paramètres de datetime et n'ajoute pas de citation aussi. – user82613

+1

Hm. Avez-vous lu la question? –

3

Je suppose que vous ajoutez des guillemets simples à votre champ datetime et que vous l'envoyez en tant que chaîne? Ne fais pas ça. Utilisez un type datetime pour le paramètre et n'y ajoutez pas de guillemets.

Il serait utile si vous nous avez montré le côté .Net du code.

+0

Il n'est pas, selon le code. –

+0

@Neil Wow, c'est vieux, mais je vais mordre. Le code qu'il a posté ne prouve pas qu'il n'y a pas de citations ici. Il ne partage pas le code pour le type 'objPropConsumer', et il est donc possible ou même probable que son membre MoveDate soit juste une chaîne. –

+1

Allez jeter un oeil à la sortie SQL par profiler dans sa question et voir "Problème ici ^^^" juste en dessous du champ de temps incorrectement cité. C'est un bug dans cette version de profiler. J'essaie seulement de ranger les choses pour les futurs chercheurs - moi inclus dans cela. –

0

objPropConsumer.MoveDate une chaîne? On dirait qu'il est peuplé d'une chaîne qui a des apostrophes au début et à la fin. Essayez de remplacer le objPropConsumer.MoveDate avec une constante '2009-04-30 00:00:00' et voir si cela fonctionne. Si c'est le cas, le problème se situe où le MoveDate est défini ou converti.

1

SP2 ou SP3 devrait résoudre ce problème dans Profiler

+0

Cela le corrige. Voir aussi: http://geekswithblogs.net/influent1/archive/2007/05/31/112897.aspx –

0

je chercherais le problème dans votre classe de base de données. Peut-être que la méthode AddInParameter() exécute un jiggery-pokery avec des paramètres DateTime, comme ajouter une chaîne formatée ou quelque chose d'idiot comme ça.

Pour une utilisation avec MSSQL, le CreateStoredProc() doit absolument renvoyer une instance de SqlCommand (il existe d'autres sous-classes de DbCommand que vous ne voulez pas utiliser). Vérifiez cela, puis assurez-vous que le AddInParameter() ajoute une instance de SqlParameter à la collection Parameters, que sa propriété DbType est DbType.DateTime et que sa propriété Value est du type System.DateTime. Une fois que les paramètres sont correctement ajoutés à un SqlCommand, cela devrait fonctionner correctement avec les procédures stockées MSSQL, également avec les données DateTime (cela a pour moi, des millions de fois).

0

Je viens de rencontrer la même chose - il s'avère que les deux guillemets simples n'apparaissaient que dans le profileur. L'erreur sous-jacente (réelle) était que je passais trop d'arguments à la procédure stockée.

Questions connexes