Feedback på lille værktøj

ikke dårligt.. slet ikke dårligt. Ikke noget jeg umiddelbart selv ville bruge, men tror det vil være godt for nogle til hurtigt at komme i gang med.

Studsede dog lidt over at du har brugt ? istede for @ til dine parametre. Ved ikke om der findes en uskreven regel omkring det, men tror du er den første jeg har set der ikke bruger @ ;)

Der er også lidt type-finurligheder i dine properties. F.eks.

        public int Id
        {
            get {return Convert.ToInt32(id);}
            set {id = value.ToString();}
        }

Hvorfor gemmer du ikke id som int i field'et?

Nu er jeg ikke super meget inde i paremetre, men vil det ikke give fejl når koden prøver at indsætte en string i et felt i databasen som er af typen int?

cyberfessor> tak fordi du gad kigge på det :-)

Ved sgu ikke helt hvorfor jeg bruger ? i stedet for @ i OleDbParameter, det er nok noget historisk - men hvis det andet er mere brugt, så vil jeg da ændre det :-)

Grunden til at jeg bruger strings til at gemme int's i min klasse, er at jeg gerne vil kunne indsætte null værdier i int kolonner i databasen. Og int er som standard ikke nullable (man kan dog bruge "int?"). Hvis jeg benytter string så vil parameterne selv indsætte null hvis strengen er lig "", da den selv sørger for en konverteringen. Men måske er den en bedre/pænere løsning på dette?

En anden ting... når du har indsat en record, så laver du det klassiske trick med

SQL = "SELECT TOP 1 per_id FROM person ORDER BY per_id DESC";

Det kan godt gøres bedre med f.eks. SELECT @@Identity, eller en-funktion-jeg-ikke-kan-huske-navnet-på() i mysql

Select()-metoden burde måske også gøre statisk, det ville jeg mene ville være mest logisk.

@@Identity er vist såvidt jeg husker noget rod hvis man benytter sig af Triggers, jeg kender ikke metoden til MySQL men vil da lige spørge google engang.

Indrømmer gerne at jeg ikke er så stærk i static, men vil er det ikke være et problem at gøre metoden static når den benytter sig af _ConnectionString fra klassen?

Access    : @@IDENTITY
SQLServer : @@IDENTITY eller bedre SCOPE_IDENTITY()
MySQL    : LAST_INSERT_ID()

Det er SCOPE_IDENTITY() som håndterer triggers bedre

tak for det Arne dem vil jeg kigge lidt nærmere på, det ser ud til at @IDENTITY på Access og LAST_INSERT_ID() kører i forhold til hver forbindelse til databasen så det er perfekt. Så må jeg lige finde ud af hvordan SCOPE_IDENTITY() virker :-)

Jeg gik ind og kiggede.

Med hensyn til data typer:

database decimal/numeric -> C# decimal

databse image/blob/ole -> C# byte[]

Alle sammen er "per connection" (eller ville de være ubrugelige).

perfekt -tak for det :-)

Jeg er naturligvis engig med cf i at fields ikke bør være string men den rigtige
data type.

Jeg mener at du bør merge constructor og Insert. Opretter man et objekt så opretter
man det.

Du kan også overveje at hold styr på om objektet er ændret eller ej.

- jeg må vist kigge lidt på mine fields ;-)

- det kunne man også gøre, måske lidt pænere - men samme funktionalitet

- ja det jo den klassiske udfordring i flerebruger systemer, er der nogen løsning der er speciel god til dette?

Det er jo ret nemt at lade property set metoder også sætte et dirty flag.

hmm dirty flag - den er jeg vist ikke helt med på?

dirty = ændret

Det giver en masse muligheder:

- automatisk update ved dispose hvis dirty

- update kald ignoreres hvis ikke dirty

- mulighed for at checke om dirty og derfor skal updates

Det er en god ide, den er blevet skrevet på listen :-)

Et lille spørgsmål til de to herrer, med hensyn til at lave fields til int så støder jeg hele tiden ind i problemet med at int's ikke kan være null. Jeg kan se at der kommer nullable types i C# 2.0.

Er der nogen bedre måde end at lade int.MinValue være lig null?

Det er et problem som skal løses. Men du ville jo få problemet alligevel
med property.

Løsningen må afhænge konteksten. Men OK din generator kender ikke
konteksten.

int.MinValue

0

Hmm...hvorfor skal det være så besværligt... ;-)

Jeg tror jeg vil arbejde videre med int.MinValue, decimal.MinValue etc. og så vente på C# 2.0.