ado obj.addnew og sql
John
Teoretisk spørgsmål. Der er noget jeg må have misset :-) Når man nu lærer
ved at prøver sig frem.
Når jeg skal indlæse en ny record i databasen, så forkommer det underligt,
at jeg skal lave en "select * ....", for at få et recordset.
Kan man ikke få et tomt record set, når man nu kun ønsker at bruge metoden
addnew. Det virker da underligt at man skal fylde en masse data i record
settet for at få lov at lave en addnew.
Nedestående virker, men er det ikke performens mæssigt i skoven (Når
datamængden vokser) ?!?!?!
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=c:\database.mdb"
Set rs = Server.CreateObject("ADODB.RecordSet")
strSQL = "Select * From stor-tabel"
rs.Open strSQL, Conn,1,3
rs.AddNew
rs("user_id")=request.cookies("loginnavn")
rs("created_by")="test"
rs("subjekt")=request("T1")
rs.Update
rs.Close
Set rs = Nothing
Conn.Close
set Conn = Nothing
john
Jonathan Stein
> Når jeg skal indlæse en ny record i databasen, så forkommer det underligt,
> at jeg skal lave en "select * ....", for at få et recordset.
Ja, det virker tåbeligt. Jeg har aldrig prøvet uden, men MS gør det i alle
eksempler. Alternativt kan de indsætte dine nye data med en et SQL kald.
Du kan formentlig også spare noget datakraft ved at tilføje "WHERE 1=2"
eller noget andet, der altid er forkert. Så får du kun et tomt recordset retur
i stedet for hele din database.
M.v.h.
Jonathan
Stig Johansen
Jonathan Stein <jst...@image.dk> wrote in message
news:3909B6A0...@image.dk...
> John wrote:
>
> > Når jeg skal indlæse en ny record i databasen, så forkommer det
underligt,
> > at jeg skal lave en "select * ....", for at få et recordset.
Når man skal indsætte en ny record i en database, er det nødvendigt at kende
feltlayoutet. Den hurtigste måde at opnå dette på er som du skriver 'select
*..'. Statementet returnerer IKKE nogle records, men returnerer bare en
cursor, der efterfølgende benyttes.
> Ja, det virker tåbeligt. Jeg har aldrig prøvet uden, men MS gør det i
alle
> eksempler. Alternativt kan de indsætte dine nye data med en et SQL kald.
> Du kan formentlig også spare noget datakraft ved at tilføje "WHERE 1=2"
Nej, lad endelig være med det, dat ikke alle optimizere er 'kloge' nok til
at undlade at gennemlæse sættes.
> eller noget andet, der altid er forkert. Så får du kun et tomt recordset
retur
> i stedet for hele din database.
Du får kun sættet retur hvis du via ADO vælger en clientside cursor.
--
Med venlig hilsen/Best Regards
Stig Johansen - st...@w3data.dk
W3 Data - mai...@w3data.dk
John
Er der noget med parameterne af gøre
rs.Open strSQL, Conn,1,3
sagt på en anden måde, kommer den første record først i memory, når man
laver movefirst, og anden record først i memory, når man laver movenext
osv...
Altså at records settet er tomt, indtil man har flyttet curseren gennem alle
records.
John
Stig Johansen skrev i meddelelsen ...
Jonathan Stein
> > Du kan formentlig også spare noget datakraft ved at tilføje "WHERE 1=2"
>
> Nej, lad endelig være med det, dat ikke alle optimizere er 'kloge' nok til
> at undlade at gennemlæse sættes.
Microsofts er formentlig - det er deres standard-eksempel...
> > eller noget andet, der altid er forkert. Så får du kun et tomt recordset
> retur
> > i stedet for hele din database.
>
> Du får kun sættet retur hvis du via ADO vælger en clientside cursor.
Så meget kender jeg ikke til ADO-arkitekturen, men det lyder logisk. På den
anden side opbygger database-driveren (eller serveren) vel et recordset (= en
liste med post-id'er), selv om det aldrig bliver overført til klienten.
Der er formentlig en grund til, at MS bruger et falsk udtryk for at få et tomt
recordset.
M.v.h.
Jonathan
Stig Johansen
John <lind...@post2.nospam.tele.dk> wrote in message
news:8ee34r$khh$1...@news.inet.tele.dk...
> En clientside, hvadfornoget ????
> Er der noget med parameterne af gøre
> rs.Open strSQL, Conn,1,3
Ja. Nu benytter jeg normalt et andet værktøj til programmering, så jeg
kender ikke lige parameterstrukturen i din open.
Men: Det er altid en god ide, at benytte konstanter i stedet for tal. Der
bør være en konstant, der fortæller hvilken cursortype, du ønsker.
adUseClient/adUseServer) ??
Hvis du bruger clientside cursor, bliver hele dit recordsæt læst ind hos
klienten, INDEN du rammer movefirst.
Hvis du bruger serverside cursor, bliver records læst succesivt når du
kalder movenext.
Som du kan se, indbefatter det også, at recordcount først kendes når man har
gennemlæst hele resultatsættet.
>
> sagt på en anden måde, kommer den første record først i memory, når man
> laver movefirst, og anden record først i memory, når man laver movenext
> osv...
Jeg vil umiddelbart tro, at den første record ligger klar i memory, ( Det
gør den i hvertfald under Delphi) og gør kaldet til movefirst unødvendig.
>
> Altså at records settet er tomt, indtil man har flyttet curseren gennem
alle
> records.
>
> John
>
[klip]
Stig Johansen
Jonathan Stein <jst...@image.dk> wrote in message
news:390B1300...@image.dk...
> Stig Johansen wrote:
>
> > > Du kan formentlig også spare noget datakraft ved at tilføje "WHERE
1=2"
> >
> > Nej, lad endelig være med det, dat ikke alle optimizere er 'kloge' nok
til
> > at undlade at gennemlæse sættes.
>
> Microsofts er formentlig - det er deres standard-eksempel...
Ja det ved jeg den er.
For et års tid eller to siden, indførte Notes også denne form for 'metadata'
retrieval. Desværre kørte vi på en anden database også, og den fyrede en
tablescan af. Heldigvis indså Notes hurtigt denne fatale fejl, og rettede
den igen.
>
> > > eller noget andet, der altid er forkert. Så får du kun et tomt
recordset
> > retur
> > > i stedet for hele din database.
> >
> > Du får kun sættet retur hvis du via ADO vælger en clientside cursor.
>
> Så meget kender jeg ikke til ADO-arkitekturen, men det lyder logisk. På
den
> anden side opbygger database-driveren (eller serveren) vel et recordset (=
en
> liste med post-id'er), selv om det aldrig bliver overført til klienten.
Serveren lave IKKE en liste, men sætter cursoren på den første record.
Records bliver derefter overført til klienten 'upon request'.
> Der er formentlig en grund til, at MS bruger et falsk udtryk for at få
et tomt
> recordset.
Det eneste M$ kan opnå her, er at undgå at overføre den første record, idet
resultatsættet vil være tomt.
>
> M.v.h.
>
> Jonathan
Stig Johansen
John <lind...@post2.nospam.tele.dk> wrote in message
news:8ec8im$rgm$1...@news.inet.tele.dk...
> Hej derude
>
> Teoretisk spørgsmål. Der er noget jeg må have misset :-) Når man nu lærer
> ved at prøver sig frem.
>
> Når jeg skal indlæse en ny record i databasen, så forkommer det underligt,
> at jeg skal lave en "select * ....", for at få et recordset.
>
> Kan man ikke få et tomt record set, når man nu kun ønsker at bruge metoden
> addnew. Det virker da underligt at man skal fylde en masse data i record
> settet for at få lov at lave en addnew.
>
> Nedestående virker, men er det ikke performens mæssigt i skoven (Når
> datamængden vokser) ?!?!?!
Jo.
Den bedste performance opnår du ved at droppe dit recordsæt, og fyre en
'INSERT INTO ...' af direkte på din connection.
I øvrigt i relation til performance, kan du se på:
http://www.microsoft.com/data/impperf.htm
I relation til denne kommentar, specielt pkt. 2.3 samt 2.14
Med hensyn til de andre ting vedrørende cursore, se pkt: 2.7
[klip]
Jonathan Stein
> For et års tid eller to siden, indførte Notes også denne form for 'metadata'
> retrieval. Desværre kørte vi på en anden database også, og den fyrede en
> tablescan af. Heldigvis indså Notes hurtigt denne fatale fejl, og rettede
> den igen.
- og så kan man jo diskuttere, om det er databasen eller forespørgslen, der
har problemet.
> > Der er formentlig en grund til, at MS bruger et falsk udtryk for at få et
> tomt
> > recordset.
>
> Det eneste M$ kan opnå her, er at undgå at overføre den første record, idet
> resultatsættet vil være tomt.
Hvis databasen løber hele datasættet igennem på en falsk betingelse, ville jeg
da ikke blive overrasket, hvis den også gjorde det på en sand.
Selv om et givet svar ikke skal overføres til klienten, skal der jo foretages
et opslag i basen, og dannes et svar-sæt (som så senere kan overføres enten
samlet eller en post ad gangen). Denne procedure kan selvfølgelig optimeres på
forskellig hvis, men det er anden snak.
Svaret på det oprindelige spørgsmål må vist være: Prøv at lave tilføjelsen
(WHERE 1=2). Bliver det hurtigere, er det fint, og bliver det langsommere, så
slet det igen.
M.v.h.
Jonathan