[ADO.NET] Insert columns met variabele lengte

[Quitter3]

Ik heb een column in een MSSQL2005 database als type varchar(50) gedefinieerd.

Vanuit een C# .Net programma wil ik hier verschillende waardes inzetten. Hiervoor gebruik ik geparameteriseerde prepared queries.

Om een parameter te creeren gebruik ik de volgende code. De parameter wordt gecached.

code:

IDbDataParameter Param = SqlCommand.CreateParameter();

Voor een insert of update, wordt de parameter uit de cache gevist en wordt gevuld:

code:

public void SetParamStr (Int32 paramNo, String value, bool encrypted,
                                Int32 encRealLength, bool isNull) {
      IDbDataParameter Param;
      if (m_LastPrepExec) {
        Param = (IDbDataParameter)m_ActiveExecCommand.Parameters[paramNo];
      } else {
        Param = (IDbDataParameter)m_ActiveQryCommand.Parameters[paramNo];
      }
      Param.DbType = DbType.String;
      if (value.Length > Param.Size) {          
          Param.Size = value.Length;
      }
      Param.Value = value;
    } // SetParamStr

Nu insert ik de volgende waardes:

A
AA
AAA
AAAA

de eerste 2 inserts gaan altijd goed. Alle inserts hierna vullen nooit meer characters dan de tweede groot was.

1e: Param.Size = 1
2e: Param.Size = 2
3e: Param.Size = 3, maar in de DB staat AA ipv AAA
4e: Param.Size = 4, maar in de DB staat AA ipv AAAA

Het is misschien een beetje een onduidelijk verhaal, maar het is te veel werk om onze DAL laag helemaal uit te leggen. De parameter size op een fixed waarde zetten kan echter niet, omdat ik niet weet wat de size is op designtime.

Het komt erop dat ADO op een gegeven moment de parameter buffer niet meer lijkt te vergroten.
Iemand enig idee wat er hier fout gaat. Google en MSDN geven hier geen uitsluitsel over. Ik zie wel dat alle voorbeelden met een fixed size werken, of elke keer de parameters opnieuw aanmaken.

[ Voor 0% gewijzigd door Quitter3 op 24-04-2007 12:32 . Reden: voorbeeld met text column niet helemaal duidelijk ]

[whoami]

Heeft die Size property wel belang bij Text columns ?
Bij een VARCHAR column wordt dit idd gebruikt om de lengte aan te geven van je varchar column (het aantal char's dat die column kan bevatten), echter, een TEXT veld is iets speciaals; je row bevat een pointer die naar een andere page wijst waar je text uiteindelijk staat.
Als je gaat gaan kijken in Sql Server Enterprise Mgr zal je ook zien dat je Text veld altijd een lengte heeft van 16bytes (die pointer) en dat je dit dus niet kunt veranderen.

[Quitter3]

Dit is niet het beste voorbeeld inderdaad. Maar het probleem doet zich ook voor bij velden van het type varchar.

Nu weten we de lengte van deze velden wel op designtime, maar we willen ze toch zo klein mogelijk allocceren. De applicaties waarin ze gebruikt worden zijn geconverteerde mainframe/cobol applicaties, waarin ook zeer grote velden (2000+) voorkomen, terwijl er mischien in de praktijk maar 100 gebruikt worden.

Ook bij deze varchars gaat het op precies dezelfde manier fout.

[whoami]

Zowiezo vraag ik me af waarom je die lengte zo wilt bepalen ? Als je een parameter definieert, geeft de lengte die je daar aangeeft gewoon de max. lengte aan; dat is, de lengte van de column in de database.
Je moet daar echt niet de lengte gaan specifieren van de value die je aan die parameter toekent.

Als het varchars zijn, zal de DB zowiezo toch enkel de nodige ruimte gaan alloceren.

[Verwijderd]

whoami schreef op dinsdag 24 april 2007 @ 21:43:
Zowiezo vraag ik me af waarom je die lengte zo wilt bepalen ? Als je een parameter definieert, geeft de lengte die je daar aangeeft gewoon de max. lengte aan; dat is, de lengte van de column in de database.
Je moet daar echt niet de lengte gaan specifieren van de value die je aan die parameter toekent.

Als het varchars zijn, zal de DB zowiezo toch enkel de nodige ruimte gaan alloceren.

Het is inderdaad overbodig om deze parameter kleiner te zetten. Als je kolom 50 lang is, zet er gewoon 50 in en niet de lengte 4 van de string. TS: Waarom gebruik je trouwens een IDbDataParameter en niet gewoon de SQL varianten? Die zijn veel sneller, aangezien die geoptimaliseerd zijn voor SQL Server.

[Quitter3]

Ik begrijp dat ik inderdaad de daadwerkelijke lengte moet gebruiken. Dat heb ik nu gedaan en dat functioneert goed. Ik blijf het echter raar vinden hoe de methode zoals ik beschreef zich gedraagt.

We gebruiken de interfaces omdat ons product zowel MSSQL, Oracl alsook DB2 ondersteund.

[whoami]

Verwijderd schreef op dinsdag 24 april 2007 @ 23:03:
[...]


Het is inderdaad overbodig om deze parameter kleiner te zetten. Als je kolom 50 lang is, zet er gewoon 50 in en niet de lengte 4 van de string. TS: Waarom gebruik je trouwens een IDbDataParameter en niet gewoon de SQL varianten? Die zijn veel sneller, aangezien die geoptimaliseerd zijn voor SQL Server.

Hij programmeert tegen de interface, maar als die interface nu toevallig een SqlParameter voorstelt, dan wordt die implementatie gebruikt.