Ok, der skal du så være meget opmærksom på, at den metode ikke virker særligt godt på diverse tekstfelter. Forestil dig f.eks. at du skal indsætte en streng der indeholder en vilkårlig kombination af \' (apostrof) og \" (anførselstegn). Der er fordelen med CreateParameter, at den kan indsætte en vilkårlig streng uden problemer. Det kan din simplere (deraf simplere ;-/) metode ikke.
Endvidere kan man - hvis man absolut vil - argumentere for, at den første metode performer bedre ved flere gentagne indsætninger, men det er nok kun af marginal interesse.
Så jo, i netop dit tilfælde med de parametre som du bruger er din anden metode simplere. Men generelt er den første metode mere sikker.
Ved at lave en Refresh på command objektet bliver de parametre, der er tilstede i SP synlige og så behøver du ikke at append parametren men bare indsætte værdien for denne!
Ved at bruge refresh og sp_myinsert & value & value kan der være performance issues, alt efter hvor meget du elsker din SQL-server. :-)
Refresh kræver et ekstra round-trip til SQL-serveren fra din applikation.
Ved at kalde din SP sp_ foran, kigger SQL-serveren automatisk i master-db\'en først.
Ved at kalde din SP men sp_myinsert & value, skal SQL-serveren først finde ud af om sp_myinsert er en stored Procedure, tabel eller view. Dette kan undgås ved at sætte: objCmd.CommandType = adCmdStoredProc
\"Ved at kalde din SP sp_ foran, kigger SQL-serveren automatisk i master-db\'en først.\" Hvorfor gør navnet en forskel ?
\"Dette kan undgås ved at sætte: objCmd.CommandType = adCmdStoredProc\"
Med sidstnævnte metode bruger jeg slet ikke Command objectet.
Hvad er det bedste kald hvis jeg kun indsætter en værdi (tal) og der ikke skal returneres noget fra SP. Det er blot en update:
Set objConn = Server.CreateObject(\"ADODB.Connection\") objConn.open \"Provider=SQLOLEDB; Data Source=127.0.0.1; Initial Catalog=db; User Id=user; Password=password;\" Set objCmd = Server.CreateObject(\"ADODB.Command\") objCmd.CommandText = \"Hitlist\" objCmd.CommandType = &H0004 Set objCmd.ActiveConnection = objConn Set objParam = objCmd.CreateParameter (\"@SPid\", 3, &H0001, 4, intParameter) objCmd.Parameters.Append objParam Set objParam = objCmd.CreateParameter (\"@SPDate\", 7, &H0001, 8, strDate) objCmd.Parameters.Append objParam Set objRS = objCmd.Execute()
ELLER:
Set objConn = Server.CreateObject(\"ADODB.Connection\") objConn.open \"Provider=SQLOLEDB; Data Source=127.0.0.1; Initial Catalog=db; User Id=user; Password=password;\" sSql = Hitlist & \" \" & intParameter objConn.Execute(sSql)
Umiddelbart virker sidstnævnte en del simplere, men det er jo ikke altid ensbetydende med bedre. Der er tale om 600.000 daglige opdateringer, så ja jeg kan godt lide min SQL Server
Brug command-objectet, med commandtype. Kald din SP \"my_insert\" istedet for \"sp_my_insert\". Du kan sætte en kommando i din SP, \"Set Nocount on\" (eks. \"Set Nocount on Insert into bla.bla.bla\"). hvis du ikke sætter den, vil din SQL-server ALTID retunerer et recordset, og det er der jo ingen grund til når det er inserts.
Det som SQL-serveren altid retunere i recordsettet er \"Rows Affected\" altså berørte poster.
Lad være med at bruge refresh, kald istedet navnet, som du allerede har gjort.
Ang. Navnet, så se ovenstående svar: Ved at kalde din SP sp_ foran, kigger SQL-serveren automatisk i master-db\'en først
Når du fyrer en insert-statement af i din Query Analyzer, vil der stå x antal rows affected. dette vil altid blive retuneret fra SQL-serveren til den kaldende part. Men kan slås fra med \"Set nocount on\".
De 2 ovenstående ting er måske småting, men jeg har den holdning at man kan ligesågodt lære sig at gøre tingene ordentligt første gang, istedet for at skulle ligge og performance tune senere. Det kommer man jo nok til alligevel, men så er der det mindre :-)
Ang. brug af object. Lad mig stille spørgsmålet: Hvad elsker du mest? Din SQL-server eller din MTS/WEB? (eller hvor du nu kører det fra). Altså for er en evt. flaskehals. Selvfølgelig optager 2 objecter mere plads end 1, og objCmd.CommandType = adCmdStoredProc bruger ikke tid på at lede igennem views og tables. Men lade det være et valg hvor du vil optimerer, istedet for skyde i blinde.
Jeg har desværre ingen reference på ovenstående, da det er noget jeg har lært på et kursus, men det hele står garanteret i Books Online eller på www.sqlteam.com
Ok, nu forstår jeg. Min database er master-db\'en, så sp_ er nok ok i mit tilfælde.
Jeg vil bruge - \"Set nocount on\".
MHT til databasen, så ligger den på samme server, så spørgsmålet er hvad der er mest ressourcekrævende overall:
Oprette et ekstra object eller lede efter navnet blandt et par views og tables. Selvom adCmdStoredProc bruges skal der jo stadig ledes blandt Stored Procedures.
Mit sidstnævnte eksempel er hentet fra 4guysfromrolla. Jeg skal ikke kunne sige hvad der er bedst. Jeg kan ikke se forskel i processor power :o) Den ligger stadig nede på et par procent med 600.000 opdateringer pr dag.
Server: Dual PIII 800 MHz 1 GB RAM 2 x 5.2 MS SCSI II drev (18GB & 9,1GB)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.