[C# & Access DB] expressie fout

[elgringo]

Ik heb een database in access. Deze heeft een tabel ('Takenpakket') met de volgende kolommen:
- Nr (int32, primaire key)
- Taakcode (string, 50)
- Naam (string, 50)
- Taakinterval (int32)
- Tijdsmarge (string, 50)
- Tijd (string, 50)
- Begindatum (datetime)
- Einddatum (datetime)

Ik heb een insert statement gemaakt:

SQL:

INSERT INTO [Takenpakket] VALUES (@nr, @taakcode, @naam, @taakinterval, @tijdsmarge, @tijd, @begindatum, @einddatum )

Alle parameters goed ingevuld (4-voudig gecontroleert), volgorde gecontroleert en zelfs nog een met een kolomnamen ervoor.
Elke uitvoering resulteert in: [Gegevenstypen komen niet overeen in criteriumexpressie.]

Ik heb ook een update statement, met dezelfde paramters als de insert (gekopieerd en geplakt) en deze doet het WEL. Deze is:

SQL:

UPDATE [Takenpakket] SET [Taakcode]=@taakcode, [Naam]=@naam, [Taakinterval]=@taakinterval, [Tijdsmarge]=@tijdsmarge, [Tijd]=@tijd, [Begindatum]=@begindatum, [Einddatum]=@einddatum WHERE [Nr]=@nr

Ik weet niet waar het mis gaat, tijdens het vullen van de parameters heeft alles een geldige waarde (geen NULL) maar toch blijf ik deze fout krijgen. Wie kan me helpen of tips geven?

[RobIII]

Is "Nr" een autoincrement?

[Verwijderd]

Heb je al geprobeerd de kolommen uit te schrijven?
Moet je Nr wel meegeven (wordt het niet gegenereerd)?
Kun je misschien de foutmelding even copy-pasten? blind

[ Voor 4% gewijzigd door Verwijderd op 17-11-2009 16:20 ]

[elgringo]

Nr is niet autoincrement, maar een gewone int32.

Wat bedoel je met kolommen uitschrijven? Maar een paar kolommen inserten ipv allemaal?

[whoami]

Hoe 'vul' je die parameters op ?
Toon eens de code hoe je een waarde geeft aan die parameters, en hoe je de parameters declareert.
Specifieer je bij het declareren van die parameters een type ?

[pedorus]

elgringo schreef op dinsdag 17 november 2009 @ 16:28:
Wat bedoel je met kolommen uitschrijven? Maar een paar kolommen inserten ipv allemaal?

SQL:

INSERT INTO [Takenpakket] ([nr], [taakcode], [naam], ...) VALUES ...

Het is best practice om de kolommen van een tabel altijd uit te schrijven. En misschien kan nr niet dus, als het een autonumber-veld is.

[elgringo]

pedorus schreef op dinsdag 17 november 2009 @ 16:37:
[...]

SQL:

INSERT INTO [Takenpakket] ([nr], [taakcode], [naam], ...) VALUES ...

Het is best practice om de kolommen van een tabel altijd uit te schrijven. En misschien kan nr niet dus, als het een autonumber-veld is.

Dit heb ik gedaan (zie openingspost) en werkte niet.

parameters worden gevuld door:

C#:

insert.Parameters["@nr"].Value=data;

insert is een DbCommand (hij kan ook met SQL werken indien gewenst). Data type komt overeen met wat gevraagd wordt: string,int32 of datetime. Er wordt geen null is gezet en ook geen object.

Dus:

C#:

insert.Parameters["@nr"].Value=1;
...
insert.Parameters["@tijd"].Value="12:00:00";
...
insert.Parameters["@begindatum"].Value=DateTime.Now;

[whoami]

elgringo schreef op dinsdag 17 november 2009 @ 21:10:
[...]


Dit heb ik gedaan (zie openingspost) en werkte niet.

parameters worden gevuld door:

C#:

insert.Parameters["@nr"].Value=data;

insert is een DbCommand (hij kan ook met SQL werken indien gewenst). Data type komt overeen met wat gevraagd wordt: string,int32 of datetime. Er wordt geen null is gezet en ook geen object.

Dus:

C#:

insert.Parameters["@nr"].Value=1;
...
insert.Parameters["@tijd"].Value="12:00:00";
...
insert.Parameters["@begindatum"].Value=DateTime.Now;

En declareer je ook de parameters en hang je daar ook een data-type aan ?

code:

insert.Parameters.Add ("@begindatum", OleDbType.DateTime).Value = DateTime.Now;

Die @tijd, welk type is dat in je DB ? Want zoals jij dat doet, zal dat niet gaan als 'tijd' een datetime type is, aangezien een datetime altijd bestaat uit een datum + tijd.

[BM]

Tijd is een string veld, zoals uit de TS blijkt.

Ik zou idd ook de manier proberen zoals whoami beschrijft. Mocht dat niet werken zou je kunnen proberen je insert statement eerst maar 1 veld te laten inserten, en dat langzaamaan uitbreiden. Op die manier kom je er snel achter welk veld er niet goed gaat (al zal dat mss ook wel in de (inner-)exception staan?), en kun je wat gerichter gaan debuggen.

[elgringo]

Parameter declaratie:

C#:

 (voor de datetime
p = this.insertCommand.CreateParameter();
p.DbType = DbType.DateTime;
p.ParameterName = "@begindatum";
p.Direction = ParameterDirection.Input;
this.insertCommand.Parameters.Add(p);

en dan vullen

C#:

this.insertCommand.Parameters["@begindatum"].Value = item.BeginDatum;

Waar de property BeginDatum een DateTime is.

Het probleem zit hetm ook in de datetime. Als ik een datetime met jaar,maand,dag,uur,minuut,seconde doe geeft hij de foutmelding. Bij een jaar,maand, dag niet.

De tijd is trouwens een string in tijd formaat. Deze wordt later geparst naar een Tijd object (maar dat is off topic).

Waarom slikt access geen seconden?
DbType.DateTime2 werkt niet en bij Date doet ie het goed met alleen jaar,maand,dag.

[Hadron]

Heb je't al eens zonder de @ geprobeerd? Volgens mij hoort die wel in je query, maar niet in je code bij het toevoegen van de parameter. De code wordt dan dus:

code:

insert.Parameters["nr"].Value=data;

Edit: Het is nog vroeg

[ Voor 6% gewijzigd door Hadron op 18-11-2009 07:52 ]

[elgringo]

En de fout staat: hier

Altijd fijn.....

[elgringo]

Hadron schreef op woensdag 18 november 2009 @ 07:52:
Heb je't al eens zonder de @ geprobeerd? Volgens mij hoort die wel in je query, maar niet in je code bij het toevoegen van de parameter. De code wordt dan dus:

code:

insert.Parameters["nr"].Value=data;

Edit: Het is nog vroeg

Is nvt het is de datetime die aan het kloten is

[DevilStudio]

Hallo,

zover ik weet kun je geen parameters gebruiken met @param1. je zult je query moeten aanpassen met

INSERT INTO <table> VALUES (? , ?, ? ......)

succes

[whoami]

DevilStudio schreef op woensdag 18 november 2009 @ 09:54:
Hallo,

zover ik weet kun je geen parameters gebruiken met @param1. je zult je query moeten aanpassen met

INSERT INTO <table> VALUES (? , ?, ? ......)

succes

Zever.
Je kan dat wel.
Het is wel zo dat je met de OleDb provider wel moet letten op de volgorde van de parameters; De OleDb provider gaat zich nl op de volgorde gaan baseren als de waardes toegekend worden,, en niet zo zeer op basis van de naam, maar je kan er wel probleemloos namen aan geven, die dan natuurlijk enkel nut hebben om de code wat leesbaarder te houden.

(Ook het feit dat dat @ niet zou mogen gebruikt worden bij het toekennen van een waarde aan een parameter is onzin).

[whoami]

elgringo schreef op woensdag 18 november 2009 @ 07:56:
En de fout staat: hier

Altijd fijn.....

Vreemd ....

Ik heb net even een klein testje gedaan (.NET 3.5, Access 2007) met de OleDbProvider en dit werkt probleemloos ... De datum wordt incl. de tijd netjes in de access file weggeschreven.

code:

private void button1_Click( object sender, EventArgs e )
{
    using( OleDbCommand cmd = new OleDbCommand () )
    {
            cmd.Connection = _conn;
            cmd.CommandText = "INSERT INTO tblTest (datum) VALUES (@datum)";
            cmd.Parameters.Add ("@datum", OleDbType.Date).Value = DateTime.Now;             
                
            _conn.Open ();

            try
            {
                cmd.ExecuteNonQuery ();
            }
            finally
            {
                _conn.Close ();
            }
      }
 }

[DevilStudio]

Ok, sorry.

Ik dacht dat MS Access niet overweg kon met de @param net zoals de @@IDENTITY etc.
Zal het nog eens proberen, heb laatst een simpel programma gemaakt met typed datasets met MS Access daar ging het niet goed.

bedankt voor de verduidelijking.

D

[whoami]

Waarom zou @@identity niet gaan in Access ?

[DevilStudio]

Hi Whoami,

Ik denk dat je inderdaad gelijkt hebt, het werkt wel. Alleen in mijn geval kon ik dat niet gebruiken in 1 query. Dat snapte de dataset designer niet. Vraag met niet waarom, gebrek aan kennis denk ik zo.

-- Dit wordt eigenlijk een nieuw topic gok ik zo ;-)

maar wat ik wilde bereiken was het volgende Add related Data primary key issue

Als je related records gaat invoeren dan krijg je van MS Access niet meteen de primary key terug, hiervoor had Beth Massi een oplossing in VB.NET door te tableadapter uit te bereiden. Echter is dit in mijn ogen niet mogelijk met C# omdat je niet bij de contstructor kunt, deze zit in de designer code.

Maar het gebruik van @param in de queries werkt inderdaad wel.

D

[pedorus]

Toch als je even googled kom je al gelijk op het mogelijke probleem met DateTime.Now. Hier zie je gelijk een advies om .ToShortDateString te gebruiken. OleDbType.Date[Time] zou het mooiste zijn, maar als dat niet werkt is dit een prima workaround.

[RobIII]

pedorus schreef op woensdag 18 november 2009 @ 10:44:
Hier zie je gelijk een advies om .ToShortDateString te gebruiken

Ik heb hier even niets bij de hand om 't te testen, maar "mijn water" zegt me dat dit op z'n bek gaat bij verschillende culture instellingen (d/m/y, y/m/d etc). Als het dan toch naar een string moet dan zegt "mijn water" dat je beter ISO 8601 kunt gebruiken (yyyymmdd formaat).
Then again zou een date(time) type gewoon moeten werken.

[ Voor 4% gewijzigd door RobIII op 18-11-2009 10:50 ]

[elgringo]

@RobIII:
Volgens de workaround werkt het als je er strings in gaat gooien. Dus DateTime.Now.ToString(). Als je DbType.Datetime heb maakt hij hier een OleDbType.Date van. Als je er een Datetime (als object) inzet gaat het mis (zie mijn link naar de report)

@Whoami
Het gaat om DbParameters (de universele abstract base class) en niet OleDbParameter. Met DbParameter kun je dmv een andere DbConnection (ja, dit is de abstract base class van oa OleDbConnection) in een hand omdraait een andere database type er aan hangen. En dat is nodig in mijn geval.

Zodra in mijn parameters ga definieren kijk ik of de DbParameter v/he type OleDbParamater is; zo ja -> OleDbType.Date anders DbType.Datetime. Nu werkt het probleemloos

[whoami]

elgringo schreef op woensdag 18 november 2009 @ 10:56:
@Whoami
Lezen blijft moeilijk... Het gaat om DbParameters (de universele abstract base class) en niet OleDbParameter. Met DbParameter kun je dmv een andere DbConnection (ja, dit is de abstract base class van oa OleDbConnection) in een hand omdraait een andere database type er aan hangen. En dat is nodig in mijn geval.

Dan heb je dat imho verkeerd opgezet.
Moest je maar per DBMS type dat je wil ondersteunen, een andere DAL geschreven hebben, die voldoet aan een bepaalde interface, en dan in je applicatie programmeren tegen je DAL-interface.
Dan kon je gewoon in je Access - DAL OleDb.Date gaan gebruiken, en in een SqlServer-DAL gewoon SqlDbType.DateTime gaan gebruiken, en had je al die miserie niet.

Zowiezo is die manier noodzakelijk als je met complexere queries aan de slag gaat; ieder DBMS heeft nl. z'n eigen SQL dialect, dus je kan niet één generiek SQL statement gaan schrijven dat je voor alle DBMS'en kunt gebruiken.
(Je kan natuurlijk ook altijd een O/R mapper gebruiken; hoef je zelf niet al die moeite te doen ... ).

Conclusie: verkeerde beslissingen genomen.

[elgringo]

whoami schreef op woensdag 18 november 2009 @ 11:06:
[...]

Dan heb je dat imho verkeerd opgezet.
Moest je maar per DBMS type dat je wil ondersteunen, een andere DAL geschreven hebben, die voldoet aan een bepaalde interface, en dan in je applicatie programmeren tegen je DAL-interface.
Dan kon je gewoon in je Access - DAL OleDb.Date gaan gebruiken, en in een SqlServer-DAL gewoon SqlDbType.DateTime gaan gebruiken, en had je al die miserie niet.

Zowiezo is die manier noodzakelijk als je met complexere queries aan de slag gaat; ieder DBMS heeft nl. z'n eigen SQL dialect, dus je kan niet één generiek SQL statement gaan schrijven dat je voor alle DBMS'en kunt gebruiken.
(Je kan natuurlijk ook altijd een O/R mapper gebruiken; hoef je zelf niet al die moeite te doen ... ).

Conclusie: verkeerde beslissingen genomen.

Wat is DAL, DBMS en O/R?

de abstracte universele base classes van DbConnection etc. worden allemaal door de specifieke sealed classes van Sql, OleDb etc gebruikt. Ik lul tegen deze interface aan (IDbConnection, IDbParameter, IDbCommand). Dit zou ook moeten werken en goed gemapt worden worden. Echter hebben de programmeurs bij MS hier wat fout gedaan wat ze ook hebben toegegeven.

Ik ben niet van plan het wiel 2keer uit te gaan vinden mbt database commando's.
Plus het feit dat ik zo makkelijk een eigen DB provider kan schrijf en laten erven van de generieke zonder problemen.

Als ik idd specifieke SQL syntax ga gebruiken werkt dit niet. Daarom doe ik dat ook niet.

Het is helemaal geen verkeerde beslissing.

[RobIII]

elgringo schreef op woensdag 18 november 2009 @ 11:24:
[...]


Wat is DAL, DBMS en O/R?

DAL, DBMS, O/R

Je hebt nog flink wat stof te lezen

[elgringo]

Nee, ik heb een hekel aan afkortingen

Ik gebruik ze alle 3

[whoami]

elgringo schreef op woensdag 18 november 2009 @ 11:24:
[...]

de abstracte universele base classes van DbConnection etc. worden allemaal door de specifieke sealed classes van Sql, OleDb etc gebruikt. Ik lul tegen deze interface aan (IDbConnection, IDbParameter, IDbCommand). Dit zou ook moeten werken en goed gemapt worden worden. Echter hebben de programmeurs bij MS hier wat fout gedaan wat ze ook hebben toegegeven.

Ik ken de class hierarchy van de System.Data classes wel zo'n beetje.
Echter, de manier waarop je dit gebruikt, lijkt me dan niet goed te zijn.
Je kan perfect tegen die interfaces & abstract classes praten, maar je moet er wel een concrete implementatie in steken, en daar moet jij er gewoon voor zorgen dat je de correcte concrete implementatie van OleDbParameter etc... creeërt, desnoods dmv een abstract factory.

Ik ben niet van plan het wiel 2keer uit te gaan vinden mbt database commando's.
Plus het feit dat ik zo makkelijk een eigen DB provider kan schrijf en laten erven van de generieke zonder problemen.
Als ik idd specifieke SQL syntax ga gebruiken werkt dit niet. Daarom doe ik dat ook niet.

Ok.
Stel dat je een lijst wilt opvragen van de 100 meest verkochte producten.
Je applicatie ondersteunt Sql Server & MySQL. Hoe ga je dat op een performante manier doen, zonder gebruik te maken van specifieke sql syntax.

Het is helemaal geen verkeerde beslissing.

Tja, .... dat vind jij.

elgringo schreef op woensdag 18 november 2009 @ 11:37:
Nee, ik heb een hekel aan afkortingen

Ik gebruik ze alle 3

Volgens mij gebruik je geen O/R in dit geval.

[elgringo]

Je kent mijn software (omgeving) niet, je kent de achtergrond niet, je weet niet wat de requirements zijn of wie er mee moet werken en toch beweer je dat het een verkeerde beslissing is. Jij moet echt god zijn!

O/R zoals ik dat snel heb gelezen is objecten mappen naar een database. Dat gebruik ik. Waar het mis gaat is bij degene die die link legt en dat doe ik met de DbConnection en wordt 1 keer gedaan.

Als ik idd de 100 meest producten wil hebben kost het me nu wat meer preformance, maar ja dat is niet het probleem. Soms is eenvoudig beter dan preformance.

Het probleem is heel simpel dat er bij Microsoft wat fout is gegaan. Dat hebben ze toegeven want het zou wel moeten werken.

[whoami]

elgringo schreef op woensdag 18 november 2009 @ 11:51:
Je kent mijn software (omgeving) niet, je kent de achtergrond niet, je weet niet wat de requirements zijn of wie er mee moet werken en toch beweer je dat het een verkeerde beslissing is. Jij moet echt god zijn!

Op basis van wat je hier verteld, vermoed ik dat je het beter anders gedaan had.

Als ik idd de 100 meest producten wil hebben kost het me nu wat meer preformance, maar ja dat is niet het probleem. Soms is eenvoudig beter dan preformance.

Eenvoudig & performance & onderhoudbaarheid is nog altijd het beste; en dat had je imho ook kunnen bereiken.

O/R zoals ik dat snel heb gelezen is objecten mappen naar een database. Dat gebruik ik. Waar het mis gaat is bij degene die die link legt en dat doe ik met de DbConnection en wordt 1 keer gedaan.

Ik doelde meer op het gebruik van een reeds bestaande O/R mapper die jou het leven makkelijker maakt, omdat je je dan niet hoeft bezig te houden met een heleboel infrastructuur-code. Niet dat het gebruik van een o/r mapper in iedere situatie te verantwoorden valt , natuurlijk.