dbimage jpg resim kaydetme

Delphi'de kod yazma ile ilgili sorularınızı bu foruma yazabilirsiniz.
Kullanıcı avatarı
mustafaozdemir
Üye
Mesajlar: 137
Kayıt: 19 Haz 2004 01:56

dbimage jpg resim kaydetme

Mesaj gönderen mustafaozdemir »

merhaba arkadaşlar firebird veri tabanımda blob alanım var ve ben buraya jpg resim kaydedemiyorum.

forumda geçen kodların hepsini denedim ama maalesef olmadı. :(
bu alan dbimage bileşeni ile ilişkili. jpg resim kaydetmeye çalıştığımda
bitmap image is not valid hatası alıyorum. blob alanımda size değeri 80 ve subtype alanı var acaba buradan kaynaklanıyor olabilir mi?
yardımcı olan arkadaşlara şimdiden teşekkürler. iyi çalışmalar.
csyasar
Üye
Mesajlar: 646
Kayıt: 25 Şub 2004 10:14
Konum: Tokat

Mesaj gönderen csyasar »

kaydetmeye çalıştığın bitmap dosyası geçerli değil. olay bu kadar basit. muhtemelen uzantısı atıyorum gif olan resmin uzantısı bmp yapılmıştır veya herhangibir sebepten dolayı(virüs bulaşması, bir programın bozması vs) dosya açılamıyor. farklı bir bmp dosyasıyla dene muhtemelen hata almazsın. zaten aldığın hata mesajı kullanılan bmp dosyasıyla alakalı.

* benim sana tavsiyem bmp dosyasını veritabanında barındırma. veritabanının boyutunu çok şişirirsin. veritabanında 10.000 tane kayıt olduğunu düşün. her kayıt için de resim olacağını düşün. her resmin boyutuda 500kb olsun(bmp resimlerinin boyutu yüksektir)

veritabanında 5.000.000 kb'lik alan meşgul eder ki; açılış kapanışlardaki kasınmalar da cabası olur. ama benim sana tavsiyem şu olur:

veritabanında tanımladığın varchar alana bmp dosyasının tam adresini tut ve ordan aç.

örneğin: C:\denemelerim\grp\cari\CR000000001.jpg gibi
ertug
Üye
Mesajlar: 82
Kayıt: 10 Ara 2004 05:41

Mesaj gönderen ertug »

csyasar yazdı:kaydetmeye çalıştığın bitmap dosyası geçerli değil. olay bu kadar basit. muhtemelen uzantısı atıyorum gif olan resmin uzantısı bmp yapılmıştır veya herhangibir sebepten dolayı(virüs bulaşması, bir programın bozması vs) dosya açılamıyor. farklı bir bmp dosyasıyla dene muhtemelen hata almazsın. zaten aldığın hata mesajı kullanılan bmp dosyasıyla alakalı.
Üzgünüm ama muhalefet edeceğim. Bence olay kaydetmeden değil, okumadan kaynaklanıyor. DBImage okuduğu blob verisinin bitmap olmasını istiyor ancak blob içerisindeki veri jpg. Dolayısıyla veritabanından blob alanı okuyup, normal bir Image nesnesine yüklemeyi deneyebilirsiniz.
csyasar yazdı:* benim sana tavsiyem bmp dosyasını veritabanında barındırma. veritabanının boyutunu çok şişirirsin. veritabanında 10.000 tane kayıt olduğunu düşün. her kayıt için de resim olacağını düşün. her resmin boyutuda 500kb olsun(bmp resimlerinin boyutu yüksektir)

veritabanında 5.000.000 kb'lik alan meşgul eder ki; açılış kapanışlardaki kasınmalar da cabası olur. ama benim sana tavsiyem şu olur:

veritabanında tanımladığın varchar alana bmp dosyasının tam adresini tut ve ordan aç.

örneğin: C:\denemelerim\grp\cari\CR000000001.jpg gibi
Buna da muhalefet edeceğim. Çoğu veritabanı blob alanları sıkıştırarak saklar ve bitmap dosyaları iyi sıkışır. Bunun dışında veritabanının dışında dosya tutup, veritabanından köprü (link) sunmak iyi bir uygulama değildir. Harici dizindeki resimler kullanıcı tarafından yanlışlıkla silinebilir veya değiştirilebilir. Bunun yerine resimleri veritabanında tutmak daha iyi bir uygulama olacaktır. Eğer performans sorunu yaşanıyorsa resimler ayrı bir tabloda tutulabilir.

Ertuğ Kaya
Kullanıcı avatarı
mustafaozdemir
Üye
Mesajlar: 137
Kayıt: 19 Haz 2004 01:56

Mesaj gönderen mustafaozdemir »

cevaplar için teşekkürler arkadaşlar. birincisi çok fazla resim kaydolmayacak. o yüzden resimleri veritabanında tutmayı düşünüyorum. ikincisi jpg resmi neden kabul etmiyor anlamadım. halbukise buradan bulduğum kodlar paradox ta çalışıyor ama firebird sorun çıkartıyor. anlamadım gitti. cevaplar için teşekkürler.
Kullanıcı avatarı
ALUCARD
Üye
Mesajlar: 1270
Kayıt: 27 Eyl 2003 10:12
Konum: Samsun
İletişim:

Mesaj gönderen ALUCARD »

ertug yazdı:
csyasar yazdı:* benim sana tavsiyem bmp dosyasını veritabanında barındırma. veritabanının boyutunu çok şişirirsin. veritabanında 10.000 tane kayıt olduğunu düşün. her kayıt için de resim olacağını düşün. her resmin boyutuda 500kb olsun(bmp resimlerinin boyutu yüksektir)

veritabanında 5.000.000 kb'lik alan meşgul eder ki; açılış kapanışlardaki kasınmalar da cabası olur. ama benim sana tavsiyem şu olur:

veritabanında tanımladığın varchar alana bmp dosyasının tam adresini tut ve ordan aç.

örneğin: C:\denemelerim\grp\cari\CR000000001.jpg gibi
Buna da muhalefet edeceğim. Çoğu veritabanı blob alanları sıkıştırarak saklar ve bitmap dosyaları iyi sıkışır. Bunun dışında veritabanının dışında dosya tutup, veritabanından köprü (link) sunmak iyi bir uygulama değildir. Harici dizindeki resimler kullanıcı tarafından yanlışlıkla silinebilir veya değiştirilebilir. Bunun yerine resimleri veritabanında tutmak daha iyi bir uygulama olacaktır. Eğer performans sorunu yaşanıyorsa resimler ayrı bir tabloda tutulabilir.
ben de buna muhalefet edeceğim
resmi dosyada tutmaktan sa resim yolunu tutmak daha mantıklı veritabanının şişmesi engellenmiş olacak
kullanıcı eğer resmi silebiliyorsa programdaki resmi de silebilir.
bunu da unutmamak lazım. kullanıcının ne işi var programın resimleriyle
bence en mantıklısı örneğin: C:\denemelerim\grp\cari\CR000000001.jpg gibi olanıdır. :wink:
بِسْمِ اللهِ الرَّحْمنِ الرَّحِيمِ
Forumun 365. Üyesi
Hiç Bir Şey İnsan Kadar Yükselemez ve Alçalamaz

Erkan ÇAĞLAR
ertug
Üye
Mesajlar: 82
Kayıt: 10 Ara 2004 05:41

Mesaj gönderen ertug »

@mustafaozdemir

Hangi yöntemle yapıyorsunuz? Birkaç satır kod gönderebilir misiniz?

@ALUCARD

> ben de buna muhalefet edeceğim

:D

> resmi dosyada tutmaktan sa resim yolunu tutmak daha mantıklı veritabanının şişmesi engellenmiş olacak

Veritabanında blob alanlar ayrı dosyalar veya bölümler şeklinde tutulur dolayısıyla zaten şişme söz konusu değildir. Ancak veritabanı olarak XML veya CSS kullanıyorsanız o zaman kesinlikle haklısınız.

> kullanıcı eğer resmi silebiliyorsa programdaki resmi de silebilir. bunu da unutmamak lazım.

Elbette ama örneğin içerisinde bin tane resim olan bir veritabanını silerseniz, yazılımınız çalışmaz. Ama ayrıca tutulan 1000 resmin 3ü silinse veya bozulsa bu durum ciddi bir sorun olabilir. Ben her zaman az dosya olan sistemleri tercih ederim, bakımı ve yedeklemesi kolay olur.

> kullanıcının ne işi var programın resimleriyle

:D Bunu onlara sormak lazım. Ama inanın bana kullanıcıların yapabileceklerinin sınırı yoktur.

Her yiğidin yoğurt yemesi farklıdır. Bu tür tartışmaların - saygı sınırlarında kaldığı sürece - çok faydalı olduğuna inanıyorum.

Ertuğ Kaya
Kullanıcı avatarı
mustafaozdemir
Üye
Mesajlar: 137
Kayıt: 19 Haz 2004 01:56

Mesaj gönderen mustafaozdemir »

Kod: Tümünü seç

 var
  jpgresim: Tjpegimage;
  blobalan: TBlobStream;
  hafiza: Tmemorystream;
  begin
   if OpenDialog1.Execute then
   Image1.Picture.LoadFromFile(OpenDialog1.FileName);
    with IBDataSet1 do
    begin
      Insert;
      jpgresim:=TJpegImage.Create;
      jpgresim.assign(Image1.Picture.bitmap);
      hafiza:=TMemoryStream.Create;
      jpgresim.savetostream(hafiza);
      blobalan:=TBlobStream.Create(TGraphicField(FieldByName('resim')), bmWrite);
      blobalan.copyfrom(hafiza,0);
      blobalan.free;
      hafiza.free;
      jpgresim.free;
   end;
kod bu arkadaşlar. daha önce forumda geçmiş bu konu burdan aldım. şu anda şöyle bir hata vermeye başladı . İnvalid class typecast.
Kullanıcı avatarı
ALUCARD
Üye
Mesajlar: 1270
Kayıt: 27 Eyl 2003 10:12
Konum: Samsun
İletişim:

Mesaj gönderen ALUCARD »

kodu birde adım adım çalıştırmayı dene istersen f8 tuşuna basarak bunu yaparsın hatayı tam olarak hangi satırda verdiğini bulmaya çalış :lol:
بِسْمِ اللهِ الرَّحْمنِ الرَّحِيمِ
Forumun 365. Üyesi
Hiç Bir Şey İnsan Kadar Yükselemez ve Alçalamaz

Erkan ÇAĞLAR
ertug
Üye
Mesajlar: 82
Kayıt: 10 Ara 2004 05:41

Mesaj gönderen ertug »

mustafaozdemir yazdı: ...
kod bu arkadaşlar. daha önce forumda geçmiş bu konu burdan aldım. şu anda şöyle bir hata vermeye başladı . İnvalid class typecast.
Merhaba,

Kod: Tümünü seç

var
  aMS: TMemoryStream;
begin
  if not (Image1.Picture.Graphic is TJPEGImage) then
    Image1.Picture.Graphic := TJPEGImage.Create; 
  Image1.Picture.Graphic.LoadFromFile('C:\Documents and Settings\All Users\Documents\My Pictures\Sample Pictures\Winter.jpg'); //Buraya dialogdan veya başka bir yerden resim koyabilirsiniz.
  aMS := TMemoryStream.Create;
  try
    Image1.Picture.Graphic.SaveToStream(aMS);
    aDataSet.Append;
    { diğer alanları doldurun }
    aMS.Position := 0; //kaydetmeden önce "stream"in en başına gidilmeli
    TBlobField(aDataSet.FieldByName('Image')).LoadFromStream(aMS);
    aDataSet.Post;
   finally
    aMS.Free;
  end;
end;
Bu kodu daha önce çeşitli vertitabanlarında denemiştim. fb'de de çalışacaktır. "Image" denilen Blob türü bir alandır.

Ertuğ Kaya
mrtyes

jpeg derdi

Mesaj gönderen mrtyes »

ya bu dbimage delphi gibi profesyonel bie dilde niye jpeg kaydetmez anlamam
bu konuda hep aynı yollar kullanılır.
ya resmin yolunu veritabanında saklarsın.
ya da bileşen indirirsin dbjpeg diye bir bileşen var .
arama yaparsan internette bulursun onu kur dene ben pek kullanamadım ama.
birde bmpyi jpege dönüştürüp image de saklayanlar var
hangisi işine gelirse
bütün yolar bu sitede mevcut
Kullanıcı avatarı
Kuri_YJ
Moderator
Mesajlar: 2248
Kayıt: 06 Ağu 2003 12:07
Konum: İstanbul
İletişim:

Mesaj gönderen Kuri_YJ »

ertug yazdı:
> resmi dosyada tutmaktan sa resim yolunu tutmak daha mantıklı veritabanının şişmesi engellenmiş olacak

Veritabanında blob alanlar ayrı dosyalar veya bölümler şeklinde tutulur dolayısıyla zaten şişme söz konusu değildir. Ancak veritabanı olarak XML veya CSS kullanıyorsanız o zaman kesinlikle haklısınız.
Nasıl yani izah eder misiniz????? Ben bir tableda bir BLOB alan tanımlayacağım ve database'im gidip bu fieldi başka bir yerde tutacak (Database dışında bir yerde) Zannedersem siz xbase'lerden bahsediyorsunuz!

RDB'lerde böyle bir şey yok, her şey tek bir dosyada (genelde bitirilir *) bunun yanı sıra transaction loglardır ki bunlar da mantıksal olarak yarı bir dosyada olmak zorundadır. DB'nin başına bir iş gelirse geri dönebilesiniz diye.

(*) : Database dosyası, Veri tabanının elverdiği imkanda büyür, bunu çok çok büyük dosyalar haline dönüştürmemek için PRIMARY File, SECONDARY Files gibi bölümlendirirler. Yani sizin DB'niz OS'inizi izin verdiği sınırları zorluyor ise Management'tan gidip DB'nin sorunsuz büyüyebilmesi için ek dosyalar verirsiniz ama daima siz TEK Bir DB'de çalışırsınız.


Yanılıyorsam düzeltin,

Kolay Gelsin
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Kullanıcı avatarı
Kuri_YJ
Moderator
Mesajlar: 2248
Kayıt: 06 Ağu 2003 12:07
Konum: İstanbul
İletişim:

Mesaj gönderen Kuri_YJ »

Selamlar,



(*) : Database dosyası, Veri tabanının elverdiği imkanda büyür,

yazmışım, aslı bu olması gerekiyor yanlış yazmışım,

(*) : Database dosyası, OS'in elverdiği imkanda büyür,


Kolay Gelsin
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
ertug
Üye
Mesajlar: 82
Kayıt: 10 Ara 2004 05:41

Mesaj gönderen ertug »

E.K.> Ancak veritabanı olarak XML veya CSS kullanıyorsanız o zaman kesinlikle haklısınız.

CSS dil sürçmesi :) CSV diyecektim.
Kuri_TLJ yazdı: Nasıl yani izah eder misiniz????? Ben bir tableda bir BLOB alan tanımlayacağım ve database'im gidip bu fieldi başka bir yerde tutacak (Database dışında bir yerde) Zannedersem siz xbase'lerden bahsediyorsunuz!

RDB'lerde böyle bir şey yok, her şey tek bir dosyada (genelde bitirilir *) bunun yanı sıra transaction loglardır ki bunlar da mantıksal olarak yarı bir dosyada olmak zorundadır. DB'nin başına bir iş gelirse geri dönebilesiniz diye.

(*) : Database dosyası, Veri tabanının elverdiği imkanda büyür, bunu çok çok büyük dosyalar haline dönüştürmemek için PRIMARY File, SECONDARY Files gibi bölümlendirirler. Yani sizin DB'niz OS'inizi izin verdiği sınırları zorluyor ise Management'tan gidip DB'nin sorunsuz büyüyebilmesi için ek dosyalar verirsiniz ama daima siz TEK Bir DB'de çalışırsınız.


Yanılıyorsam düzeltin,

Kolay Gelsin
Biraz kapalı anlatmışım sanırım. Blob alanlar veritabanlarında farklı bir bölümde tutulurlar. Farklı bir bölüm, mutlaka farklı bir dosya anlamına gelmez. Örneğin bir zip dosyasının içerisinde bir çok farklı dosya vardır ancak zip dosyası *dışarıdan bakıldığında* tek bir dosyadır.

Genellikle veritabanları sabit uzunluklu alanlar olarak kaydedilirler. Her gireceğiniz alan için ya önceden tanımlanmış bir uzunluk vardır (integer için 4 byte gibi) veya uzunluğu siz belirlersiniz (string için 40 karakter gibi).

Bu durumda her bir satırın -diyelim ki- 100 byte kapladığı bir tabloda ilk kayıt birinci byttan başlıyorsa 10. kayıt 901. byte'tan başlayacaktır ve 1000. byte'da bitecektir.

Ancak bazı durumlarda önceden bilinemeyecek uzunluklar olabilir (blob veya null ile sonlandırılan karakter dizinleri gibi). Bu değişken alanlar tablolama mantığına ters düşerler. Bu yüzden bu alanların içeriği farklı bir bölümde tutulurken, tablo içerisinde bu alanların içeriğine giden işaretler (pointer) tutulur (ki bunlar genelde 8 veya 16 byte olurlar). Bu durumda satır uzunlukları yine sabit kalacaktır ancak değişken uzunluklu alanlar da tutulabilecektir.

Paradox gibi çok dosyalı veritabanlarında, bu değişken uzunluklu alanlar ayrı bir dosyada tutulurken, access gibi tek dosyalı veritabanlarında bunlar bir dosyanın içerisinde *ancak farklı bir bölümde* tutulurlar.

İyi bir anlatım olmadı :oops: ama sanırım biraz daha netleşmiştir.

Ertuğ Kaya
Kullanıcı avatarı
Kuri_YJ
Moderator
Mesajlar: 2248
Kayıt: 06 Ağu 2003 12:07
Konum: İstanbul
İletişim:

Mesaj gönderen Kuri_YJ »

Selamlar,

Elbette Aynı Dosyanın içinde farklı bir yerlerde tutar aksi takdirde esnekliği veremez. Ancak yine de tek bir dosyada durur herşey.

Ama yine de image'lerin DB'de tutulması DB'yi şişirir ve yavaşlatır. Neden diyecek olursanız, her ne kadar ayrı bölümler halinde de tutsa siz select çektiğiniz anda, eğer çektiğiniz select'de bir blob alan var ise mecbur bu alanı da select etmiş olursunuz. Dönen result set de sizizn imageleriniz sayesinde şişer de şişer :)

Ayrıca OS'in File Managementi de bu blobların yazılması ve okunması sırasında DB'ye ayak bağı olur. Şişen dosya işetim sisteminden kaynaklı yavaşlamalar neden olacaktır. Bu nedenle baba SQL Server üreticileri (Oracle gibi) kendi file systemlerini tercih ediyorlar. Yani herhangi bir diske kendi File Management'ini kurarak Data disk yapıyorlar. İşletim sistemini karşıtırmıyorlar o noktada.

Kolay Gelsin.
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
ertug
Üye
Mesajlar: 82
Kayıt: 10 Ara 2004 05:41

Mesaj gönderen ertug »

Kuri_TLJ yazdı:Selamlar,
Ama yine de image'lerin DB'de tutulması DB'yi şişirir ve yavaşlatır. Neden diyecek olursanız, her ne kadar ayrı bölümler halinde de tutsa siz select çektiğiniz anda, eğer çektiğiniz select'de bir blob alan var ise mecbur bu alanı da select etmiş olursunuz. Dönen result set de sizizn imageleriniz sayesinde şişer de şişer :)

Ayrıca OS'in File Managementi de bu blobların yazılması ve okunması sırasında DB'ye ayak bağı olur. Şişen dosya işetim sisteminden kaynaklı yavaşlamalar neden olacaktır. Bu nedenle baba SQL Server üreticileri (Oracle gibi) kendi file systemlerini tercih ediyorlar. Yani herhangi bir diske kendi File Management'ini kurarak Data disk yapıyorlar. İşletim sistemini karşıtırmıyorlar o noktada.

Kolay Gelsin.
Çok doğru noktalara değinmişsiniz. İki farklı yöntemi inceleyelim:

Senaryo 1. Resimler veritabanı dışında farklı yerde tutuluyor, bir koşulu sağlayan kayıttaki resme ulaşmak için:

Adım 1. Sorgu yapılır.
Adım 2. Kayıt belirlendikten sonra resmin adresi alınır. Alınan adresten resim okunur.

Senaryo 2. Resimler veritabanı içerisinde:
Adım 1. Select kısmında resim olmayan sorgu yapılır.
Adım 2. Kayıt belirlendikten sonra resmi alacak ikinci bir sorgu yapılır ve resim okunur.

İki senaryoda da yapılacak işlem iki adımdan oluşuyor. Ancak birinde resimler açıkta ve dağınık durumda ikincisinde toplu durumda. Eğer sorgunuzda resim alanını sorguya dahil etmezseniz bir yavaşlama olmayacaktır.

İşletim sisteminden kaynaklanan yavaşlıklar oluyorsa bu durumda dışarıdan resim okumak daha problemli olabilir. Özellikle bir dizin altındaki dosya sayısı arttıkça eski işletim sistemleri performans olarak yavaşlayacaktır. Böyle bir durumda kendi dosya yapısını kullanan veritabanları daha performanslı çalışabilir.

Yine de iki sistemin artı ve eksileri göz önüne alınıp en doğrusunu seçmek iyi bir programcılık uygulaması olacaktır. Mühendislik de zaten bu değil midir? :D

Ertuğ Kaya
Cevapla