Database!

Hvis du i database desktop, i den pågældende tabel, opretter et felt af typen \"graphics\", har du gjort plads til et billede (typisk BMP)

Lad os kalde det \"billede\".

Derefter anvender du på din form et DBImage komponent der peger du det felt i din database.


Du kan herefter udfylde den med en onclick event for en knap på følgende måde:

if table1.state in [dsedit,dsinsert] then
begin
  OpenDailog1.Filter    := \'Bitmap filer (*.bmp)|*.bmp|Alle filer (*.*)|*.*\';
  OpenDialog1.initialdir := \'c:\\\';
  if OpenDialog1.execute then
  begin
    table1.fieldbyname(\'billede\').loadfromfile(OpenDialog1.filename);
  end;
end;

Herefter vil den være loadet ind i feltet og du kan se den når du bladrer gennem databasens records. MEN bemærk: Du kan ikke se billedet i en DBGrid. Det er nødvendigt at tilføje et DBImage komponent og lade det pege på hhv. datasourcen og feltet i databasen.

MEn så virker det også fint.

Det var dog en rigtig nydelig lille \'load rutine\' du kom med der...

Delphi

Delphi, jeg plejer egentligt at sætte feltnavnene ind i tablet (højreklik på tablet og vælg \"Add fields\"). Derefter arbejder jeg med table1feltnavn.value istedet for den måde jeg har vist det på her.

Således vil loadfunktionen normalt være:

table1billede.loadfromfile(opendialog1.filename);

At indsætte en TImage i en database:

  with ttable.create(nil) do
  try
      DataBaseName := \'\';
      TableName := \'billedfil.db\';
      with FieldDefs do
      begin
        Clear;
        Add(\'Billede\',ftGraphic,0,false);
      end;
      CreateTable;
      Open;
      Append;
      TBlobField(FieldByName(\'Billede\')).Assign(Image1.Picture.Bitmap);
      Post;
      close;
  finally
      free;
  end;

Sjensen> Jeg havde nu slet ikke \"fieldbyname\" i tankerne da jeg skrev ovenstående.  Det var mere ideen med at teste på State (med et set) og så benytte filename værdien fra en OpenDialog til at loade filen direkte ind i tabellen - fikst og effektivt. 
Mht. at tilføje fields til form erklæringen ved design, så kan jeg kun give dig ret.  Jeg kan kun anbefale at man, hvis det er muligt, altid benytter denne metode.  Derved undgår man problemer med fields der bytter plads osv.  Der er se\'følig situationer hvor det ikke er praktisk, fx. med run-time queries og TTables der først bindes til fysiske tabeller under runtime.  I disse situationer er FieldByName mv. da et udemærket alternativ, men jeg har en mistanke om at de ikke er nær så effektive, ret tidsmæssigt - det sidste har jeg dog aldrig afprøvet i praksis.

Delphi

Gummmiand> Irk, grim kode!  Type casts og meget andet godt.... Er du C++ programmør?? :)

Iøvrigt:  I forbindelse med noget nyt arbejde er jeg er ved at sætte mig lidt dybere ind i C++ (VC6).  Jeg har kun en mening:  Delphi er LANGT nemmere at bruge.  Fx. bare det at indsætte en Editbox på en form kræver mindst tre gange så handlinger på design tidspunktet.  Under runtime skal man kalde suspekte rutiner, så som UpdateData() - hvortil man aldrig kan huske om parameteren er \"FALSE\" eller \"TRUE\" (Endelig ikke \"False\" eller \"True\" for så brækker compileren sig).  Alt i alt: C++ er et latterligt sprog! som jeg kun bruger fordi jeg er tvunget til det!

Delphi (fan!)

Delphi> Hvilket \"andet godt\" ?

Delphi, som en forlængelse af din kommentar vil jeg lige fortælle at jeg for kort tid siden har leveret et delphisystem, der internt arbejder med nogle felter og felttyper, der alle er defineret i en MSSQL db, og hvor al kommunikation foregår via SQL. Delphi programmet vedligeholder ingen registre selv, men henter og gemmer alle data i SQL db\'en. Delphi programmet bruger kun paradox registre til de statiske oplysniger der fremgår af nedenstående.

For at gøre denne binding så fleksibel som muligt, og netop undgå bindinger til feltnavne, typer og feltrækkefølger i forespørgsler og opdateringer o.s.v., arbejder delphi programmet med faste feltnavne og (og typer) internt, og via et \"krydsref\" register, der indeholder det interne feltnavn, og det tilsvarende MSSQl feltnavn (og type, længde m.m.) samt navnet på det parameter der indgår i f.eks. opdateringskald, håndterer en rutine at hhv. decifrere modtagne data fra SQL ind i de interne felter (ved at sammenligne interne og eksterne felter), og ved opbygnign af SQL kald at oversætte interne feltnavne til de eksterne SQL feltnavne der fremgår af \"krydsref\" registret. Og samtidig vedligeholder Delphiprogrammet et paradox register med navnene på de forskellige tables og stored procedures der findes i SQL db\'en og bruger disse navne ved opbygningne af SQL kaldet.

Dermed har kunden fri mulighed for at ændre på sin MSSQLL database som han har lyst (tabeller, felter og stored procedures), og ved at lave tilsvarende ændringer i Delphiprogrammets \"krydsref\" registre vil programmet kunne håndtere ændringerne uden at programmet skal ændres og re-compileres.

Det er faktisk ganske smart og kunden er meget glad for at den binding der ellers ville kræve programændringer når han ændrer sin database, ikke længere findes, selvom programmet er afhængigt af den pågældende database.

Kan du se hvad jeg mener ?

Tror det - det lyder lidt kryptisk, men jeg fik vist den grundlæggende mening: At have en slags interface database mellem appilcationen og så de ændringen brugeren laver i den bagvedliggende DB.

Ja, det er kort sagt sagen i en nøddeskal ;-)