SCOPE_IDENTITY() par rapport à rs.Fields

Question

quelle est la différence dans la façon dont ces travaux:

Sql = "INSERT INTO mytable (datapath, analysistime,reporttime, lastcalib,analystname,reportname,batchstate,instrument) " & _ 
     "VALUES (dpath, atime, rtime,lcalib,aname,rname,bstate,instrument) SELECT SCOPE_IDENTITY()" 

Set rs = cn.Execute 
Set rs = rs.NextRecordset 

et ceci:

With rs 
    .AddNew ' create a new record 
    ' add values to each field in the record 
    .Fields("datapath") = dpath 
    .Fields("analysistime") = atime 
    .Fields("reporttime") = rtime 
    .Fields("lastcalib") = lcalib 
    .Fields("analystname") = aname 
    .Fields("reportname") = rname 
    .Fields("batchstate") = bstate 
    .Fields("instrument") = instrument 

    .Update ' stores the new record 
     id=fields.Fields("rowid") ' ** Answer to Question ***  
End With 

ma question est précisément ceci:

je suis dans un environnement multi-utilisateur. immédiatement après que l'utilisateur ajoute un enregistrement, j'ai besoin d'attraper le ROWID de l'enregistrement ajouté. Comment puis-je faire cela?

Voilà comment j'ouvre le jeu d'enregistrements:

rs.Open "batchinfo", cn, adOpenKeyset, adLockOptimistic, adCmdTable 

Answer 1

Les différents est la façon dont vous ajoutez le dossier et revenir le résultat. Dans le premier cas, vous émettez une instruction INSERT suivie d'un appel au SCOPE_IDENTITY. Dans le second cas, vous ouvrez un curseur pouvant être mis à jour, y ajoutez un enregistrement et relisez le nouvel enregistrement ajouté.

L'ouverture d'un curseur peut être une opération gourmande en ressources (cela dépend de la façon dont vous le faites). Il peut également dégrader la concurrence.

Answer 2

Votre premier exemple de code n'est pas légal dans SQL Server. Quels sont les noms après la clause VALUES supposée être? Je suppose qu'ils sont censés être des paramètres mais vous ne pouvez pas passer de paramètres comme ça. Y a-t-il une raison pour laquelle vous n'utilisez pas une procédure stockée paramétrée et des objets de paramètres pour transmettre des paramètres?

Answer 3

La plupart du temps j'utilise le jeu d'enregistrements ouvert, ajouter des données, mettre à jour, saisir la méthode d'identification cependant que Quassnoi a dit qu'il peut être ressource intensive. Pour les parties de l'application qui sont appelées beaucoup ou doivent s'exécuter aussi vite que possible, j'ai tendance à utiliser une procédure stockée avec l'ID de la nouvelle ligne comme paramètre de retour.

Voici un exemple de code

Set cmd = New ADODB.Command 

With cmd 

    .CommandText = "sptblTest_questions_UPSERT" 
    .CommandType = adCmdStoredProc 
    .ActiveConnection = dbCon 

    .Parameters.Append .CreateParameter("@Question_ID", adInteger, adParamInput, 0, Me.txtQuestion_ID) 

    .Parameters.Append .CreateParameter("@Section_ID", adInteger, adParamInput, 0, Me.txtSection_ID) 

    .Parameters.Append .CreateParameter("@Question_number", adTinyInt, adParamInput, 0, Me.txtQuestion_number) 

    .Parameters.Append .CreateParameter("@Question_text", adVarChar, adParamInput, 1000, Me.txtQuestion_text) 

    .Parameters.Append .CreateParameter("@Max_score", adSmallInt, adParamInput, 0, Me.txtMax_score) 

    .Parameters.Append .CreateParameter("@User", adVarChar, adParamInput, 50, fOSUserName) 

    .Parameters.Append .CreateParameter("@Inserted_ID", adInteger, adParamOutput, 0) 

    .Execute 

    Me.txtQuestion_ID = .Parameters("@Inserted_ID") 

End With