[ASP] lege datum ingeven bij inserten in DB

[Verwijderd]

kheb een probleem met inserten van een datum in een access db.
Als de datum is ingevuld, is er geen probleem. Maar er mag ook geen datum ingevuld worden, dan is de variabele leeg. Als ik nu uitvoer

sql = "insert in db (datum) values ('"&vardatum&"')" "
conn.execute(sql)

geef ie een error [Microsoft][ODBC Microsoft Access Driver] Data type mismatch in criteria expression, omdat de variabele natuurlijk een datum is. Nochthans kan in de databank een leeg datumveld ingegeven worden.

wie kan het me vertellen?

thx

[whoami]

Check of de datum ingevuld is, en als hij ingevuld is, insert je hem, anders insert je een NULL.
En kijk ook eens naar parametrized queries.
[sub]* whoami blijft het hier maar herhalen....[/sub]

[BlackBurn]

Dan ga ik vast een domme vraag stellen, maar wat zijn "parametrized queries" ?

Trouwens waarom voegt iedereen data in via een SQL opdracht, ik doe het altijd met behulp van een RecordSet en AddNew, is toch veel overzichtelijker?

[gorgi_19]

BlackBurn schreef op 06 april 2004 @ 11:25:
Dan ga ik vast een domme vraag stellen, maar wat zijn "parametrized queries" ?

Trouwens waarom voegt iedereen data in via een SQL opdracht, ik doe het altijd met behulp van een RecordSet en AddNew, is toch veel overzichtelijker?

Zie FAQ

En waarom niet? Performance enzo?

[BlackBurn]

Weer wat geleerd, het is misschien wel wat meer werkt, maar op die manier is het wel overzichtelijker en schijnbaar dus ook sneller

edit: is het via de recordset dan zo traag?

[ Voor 15% gewijzigd door BlackBurn op 06-04-2004 11:41 ]

[Verwijderd]

probeer het anders is zo

sql = "insert in db (datum) values (#"&vardatum&"#)" "
conn.execute(sql)

[whoami]

Verwijderd schreef op 06 april 2004 @ 11:58:
probeer het anders is zo

sql = "insert in db (datum) values (#"&vardatum&"#)" "
conn.execute(sql)

Dat is een slechte manier.
Beter is het om parametrized queries te gebruiken. Dan heb je helemaal geen last meer met quotes, datumformaten, geen last van sql injection, etc....

Gebruik maken van de addnew methods van de recordset vind ik ranzig. Het is minder flexibel, trager, en achter de schermen moet er toch een sql statement gemaakt worden.

[ Voor 19% gewijzigd door whoami op 06-04-2004 12:04 ]

[Verwijderd]

je kan sql injection al voorkomen door simpelweg ' te vervangen door '' en qwa performance scheeld het weinig met kleine querys als deze.

[whoami]

Verwijderd schreef op 06 april 2004 @ 12:09:
je kan sql injection al voorkomen door simpelweg ' te vervangen door '' en qwa performance scheeldt het weinig met kleine querys als deze.

En wat als ik dan dit ingeef als naam bv:

code:

D'artagnan

Dan zit je met de gebakken peren.

En wat als ik een datum ingeef in een ander formaat ?

Trouwens, dat replacen is prutsen en kan voor ongewenste situaties zorgen.

[ Voor 9% gewijzigd door whoami op 06-04-2004 12:13 ]

[Verwijderd]

whoami schreef op 06 april 2004 @ 12:12:
[...]


En wat als ik dan dit ingeeft als naam bv:

code:

D'artagnan

Dan zit je met de gebakken peren.

En wat als ik een datum ingeeft in een ander formaat ?

Trouwens, dat replacen is prutsen en kan voor ongewenste situaties zorgen.

dan gebeurd er niks als je van ' '' maakt denk ik

[ Voor 5% gewijzigd door Verwijderd op 06-04-2004 12:20 ]

[whoami]

Als ik ingeef is zonder t. Bij de 3de persoon komt er een t bij.

Als je die string replaced, dan krijg je dit:

code:

insert into tabel ( naam ) 
values
("d"artagnan")

En dit zal een SQL error tot gevolg hebben.

[Pathogen]

erg fijn volgens mij kon je ook deze-> ` haakjes gebruiken in sql... weet het niet zeker

[party42]

gewoon lekker escapen

code:

insert into tabel ( naam ) 
values("d&artagnan")

Maar whoami heeft gelijk hoor. PQ gebruiken! Is good practice.

[Verwijderd]

code:

&

dan moet je nooit doen, als je de html er van uit wil halen zie je geen ' meer.

eneh ik zeg ook niet dat hij ongelijk heeft ik zeg alleen dat het ook op andere (makkelijkere) manier kan

[j_du_pee]

whoami schreef op 06 april 2004 @ 12:19:
Als ik ingeef is zonder t. Bij de 3de persoon komt er een t bij.

Als je die string replaced, dan krijg je dit:

code:

insert into tabel ( naam ) 
values
("d"artagnan")

En dit zal een SQL error tot gevolg hebben.

Er stonden twee enkele quotes, niet 1 dubbele. HTML inserten zou ik sowieso niet doen party42

Persoonlijk vind ik sql strings heerlijk overzichtelijk werken en als ik performanceproblemen zou moeten zoeken in het verschil query/parameterized zou ik toch eens kijken of er niet ergens anders iets fout zit.

Ik vind het persoonlijk per situatie verschillen wat je gebruikt, het is aan de programmeur hoe hij dit invult. Het keer op keer wijzen dat het een beter is dan het ander wordt IMHO vervelend.

[whoami]

Verwijderd schreef op 06 april 2004 @ 12:26:
eneh ik zeg ook niet dat hij ongelijk heeft ik zeg alleen dat het ook op andere (makkelijkere) manier kan

't Is maar wat je makkelijker noemt.
Replacen is misschien initieel minder werk, maar door parametrized queries te gebruiken vermijd je heel wat problemen die zich later kunnen voordoen.

De makkelijkste weg, is niet altijd de beste weg.

[Verwijderd]

Als je die string replaced, dan krijg je dit:

code:

insert into tabel ( naam ) 
values
("d"artagnan")

En dit zal een SQL error tot gevolg hebben.

Volgens mij krijg je dan dit en dat werkt uitstekend:

code:

insert into tabel ( naam ) 
values
('d''artagnan')

Maar dat terzijde. PQ's zijn beter.

[ Voor 8% gewijzigd door Verwijderd op 06-04-2004 12:30 ]

[whoami]

j_du_pee schreef op 06 april 2004 @ 12:27:
[...]


Persoonlijk vind ik sql strings heerlijk overzichtelijk werken en als ik performanceproblemen zou moeten zoeken in het verschil query/parameterized zou ik toch eens kijken of er niet ergens anders iets fout zit.

dat is ook niet de reden om PQ's te gaan gebruiken. Het is gewoon een bijkomend voordeel bij parametrized select queries die een paar keer moeten uitgevoerd worden. Het execution plan wordt nl. bewaard en hergebruikt.
Als er een wezenlijk verschil zit in de performance zal het idd wel ergens anders aan liggen.

[whoami]

j_du_pee schreef op 06 april 2004 @ 12:27:
[...]

Ik vind het persoonlijk per situatie verschillen wat je gebruikt, het is aan de programmeur hoe hij dit invult. Het keer op keer wijzen dat het een beter is dan het ander wordt IMHO vervelend.

OK, dan zeg ik er niets meer over, en zoekt iedereen het zelf maar uit.
Wat de bedoeling van dit forum dan wordt, wordt mij dan een beetje onduidelijk.

[j_du_pee]

wat mij betreft is het doel om problemen op te lossen. Een frequent lezer leert er een hoop bij over aanliggende zaken, maar wil primair zijn probleem opgelost zien.
Als ik een stuk code zie, waarbij iemand een typfout maakt in zijn variabelenaam waardoor een error ontstaat, wijs ik hem op die error. Ik maak er geen discussie over de voors en tegens van de hongaarse naamgeving van variabelen van.

In principe is dat ook wat jij deed in dit topic Alleen zie ik zoveel toopics met een error verzanden in een PQ voors en tegens discussie...

[party42]

Volgens mij zijn we het stadium van voor & tegens van PQ's ook al lang voorbij. Overigens ben ik het whoami eens hoor.

Kijk, we kunnen nog 1000 topics gaan openen met allemaal mogelijke Replace functies omdat dat zo lekker makkelijk is. Vervolgens voorzie ik dat er dus nog 1000 ruk applicaties ontstaan omdat de programmeur niet even de moeite wilde nemen om een iets moeilijkere oplossing in te bouwen, maar voor de quick fix ging.

Als iedereen gewoon nu snel PQ's gaat gebruiken hoeven we dit soort zaken niet meer op te lossen. Dan hoeven we alleen nog maar te verwijzen naar de FAQ. (dat doen we anders nooit dus... )

[whoami]

j_du_pee schreef op 06 april 2004 @ 12:38:
wat mij betreft is het doel om problemen op te lossen. Een frequent lezer leert er een hoop bij over aanliggende zaken, maar wil primair zijn probleem opgelost zien.
Als ik een stuk code zie, waarbij iemand een typfout maakt in zijn variabelenaam waardoor een error ontstaat, wijs ik hem op die error. Ik maak er geen discussie over de voors en tegens van de hongaarse naamgeving van variabelen van.

In principe is dat ook wat jij deed in dit topic Alleen zie ik zoveel toopics met een error verzanden in een PQ voors en tegens discussie...

De topicstarter kan er juist veel uit leren door een bijkomende discussie te voeren. Daarnaast is het hier een forum, en mag er een bijkomende discussie gevoerd worden.
Dat het niet bijdraagt tot het initiële probleem van de topicstarter, so be it. Hij kan uit die discussie ook leren, en het is hier nu eenmaal een forum, geen 'quickservice waar enkel fouten snel en zonder kosten opgelost worden'.
Kijk maar eens naar een heleboel C++ topics: in de meeste ervan wordt er ook een heel andere discussie aangesneden, die meestal heel interessant en leerzaam is. Het zijn juist zo'n dingen die het forum leuk en interessant maken.
Als jij vindt dat het niet zo is, dan lees je er toch gewoon over, en trek je je er niets van aan.