arkadaşlar merhaba,
şöyle bir problemim var veritabanında float tanımlı borcu alanına delphiden kod ile float rakam gönderiyorum.
örneğin veritabanında
borcu=7.775,89 olsun
ben delphiden kod ile 15,55 değerini boru alanının üzerine kaydetmek istediğim zaman
borcu = 7.791,44 olması gerekirken
borcunu 9330,89 yapıyor kısaca virgüllü küsurat kısmını görmeden rakamın tamamını ekliyor,
virgülü . yaparak göndermek istediğimde ise hata veriyor
bu problemi nasıl halledebilirim
Teşekkürler
Burak Bitikçi
float rakamların veri tabanına kaydedilmesi
Forum kuralları
Forum kurallarını okuyup, uyunuz!
Forum kurallarını okuyup, uyunuz!
-
serkan1634
- Üye
- Mesajlar: 17
- Kayıt: 13 Nis 2005 10:37
virgüllü
burakcım hangi veritabanını kullanyosun bilmiyorum ama float tanımlamak yerine veritabanında o alanı $money olarak tanımla ve programında da dbedit kullan sorunun çözülmüş olacaktır. kolay gelsin...
her şey yaratana dönüşten ibarettir
float sayılar
selamlar hocam ben de de öle bir sorun vardı ben de sunu yaptım. firebird kullanıyorsan alanları numeric olarak verirsen rahat olur. gerçekten de scale kısmını 2 olarak ayarla. ondan sonra kullanımında herhangi bir sorun da olmuyor.
-
doganzorlu
- Kıdemli Üye
- Mesajlar: 395
- Kayıt: 22 Tem 2004 09:15
- Konum: İzmir
- İletişim:
Selam,
Veritabanı uygulamalarında gerek karakter ve gerekse sayısal alanlar değişik nedenlerle dönüşüme uğrarlar. Örneğin sisteminizin server bileşeni bir unix de, web server Linux da sizin uygulama da windows larda çalışıyor. Birkaç ufak bölümü de Kylix yazdınız yine terminallerde çalışıyor. Örneği özellikle abartılı verdim olayı belirtmek için.
Karakter dönüşümün amacı ulusal dillerin hem karakterlerini ve hem de sıralama şeklini desteklemektir. Bu anlamda veritabanındaki bilginin prezentasyonunu yapan istemcinin dili ve veritabanının dili diye iki kavram ortaya çıkmaktadır. Şayet veritabanı ve istemci arasındaki katman bu dönüşümü düzgün yapabiliyorsa sorun olmaz. Ama zaman zaman bu katmanın desteklemediği konfigürasyonlar ortaya çıkar ve saç baş yoldurur. Çoklu istemcili sistemlerde bu daha yoğun yaşanan bir durumdur. Windows terminalde Ş olarak girilen harfin sistemin diğer bölümlerinde de bu şekilde görülebilmesi önemlidir. UTF bu konuda iddialı ama henüz uygulamada aksayan çok şey var.
Sayısal alanlar ise bu durumdan nokta ve virgül (bin ve decimal ayıracı) ile etkilenmektedir. Veritabanına birkaç yöntemle veri gönderebilir ve yine birkaç yöntemle alabilirsiniz. Doğrudan bir DML komut gönderdiğinizde, server ve kendi sisteminizdeki ulusal ayarları bilmeniz gerekir zira gönderdiğiniz alan ne olursa olsun karakter katar içinde gidecektir. Sunucu bunu alıp analiz ettiğinde virgül e ne anlam yükleyecek bilemezsiniz. Bunun yerine dönüşümleri sizin adınıza yapması için iletişim katmanından yardım alamak daha akıllıca olacaktır. Binary decimal notasyon tek olduğu için, bu katman bilgiyi iki taraflı dönüştürebilir. Delphi ile kullanacağınız komponentler sayısal alanları sistemin ayarlarından aldıkları bilgi doğrultusunda nokta virgül notasyonunda gösterebilirler. Fakat bu sizin bu bileşenlerin içeriğini bir sql e koyup gönderebilmenize olanak sağlamaz. Zira dönüşümün ters yönünü de sizin yapmanız gerekecektir. Veritabanı için aslında bir tek karakter önemlidir decimal ayıraç olan değer. Bu ise yukarıda da dediğim gibi istemci tarafındaki değer olmayabilir. Bu topiğin başlangıcında anlatılan olay tam olarak bu duruma işaret ediyor. Stored procedure ile bulunan çözümde parametreler sayısal olarak gönderildiği için dönüşüm iletişim katmanında çözümlendiğinden sorun yaşanmamıştır. Şayet SQL i doğrudan gönderip o string i sp içinde execute ederseniz aynı sorun yine olacaktır.
Sona doğru biraz dağıldı ama durum budur. 4GL dillerde bu dönüşüm daha abartılıdır zira SQL istemci tarafında oluşur analiz edili ve aradaki katman gereken düzenlemeyi yapıp sunucuya öyle gönderir. Bu nedenle geliştiriciler bu gibi işlerle ilgilenmezler.
--- EK ---
Şayet doğrudan SQL oluşturmuyor ve DB bileşenleri kullanıyorsanız sizin adınıza bu işi kimin yaptığını merak ediyor olabilirsiniz. Şayet bir ODBC sürücü kullanıyorsanız ilk bağlantıda sunucu locale bilgilerini alıp kendisine gelen SQL isteğini sunucunun anlayacağı şekle dönüştüren bu sürücüdür. Yok doğal bir sürücü kullanıyorsanız bu kez de bu sürücü bu dönüşüm ve SQL oluşturma işini üstlenir. Böylelikle sunucuya aslında hep normalize edilmiş saf SQL ler gelir. Gerçekte SQL olmayan db lere yazarken zaten bir SQL oluşturulmaz db ye erişen bileşen onu alır uygun şekilde kaydeder zira bunlarda sunucu yoktur..
Kolay gelsin,
Veritabanı uygulamalarında gerek karakter ve gerekse sayısal alanlar değişik nedenlerle dönüşüme uğrarlar. Örneğin sisteminizin server bileşeni bir unix de, web server Linux da sizin uygulama da windows larda çalışıyor. Birkaç ufak bölümü de Kylix yazdınız yine terminallerde çalışıyor. Örneği özellikle abartılı verdim olayı belirtmek için.
Karakter dönüşümün amacı ulusal dillerin hem karakterlerini ve hem de sıralama şeklini desteklemektir. Bu anlamda veritabanındaki bilginin prezentasyonunu yapan istemcinin dili ve veritabanının dili diye iki kavram ortaya çıkmaktadır. Şayet veritabanı ve istemci arasındaki katman bu dönüşümü düzgün yapabiliyorsa sorun olmaz. Ama zaman zaman bu katmanın desteklemediği konfigürasyonlar ortaya çıkar ve saç baş yoldurur. Çoklu istemcili sistemlerde bu daha yoğun yaşanan bir durumdur. Windows terminalde Ş olarak girilen harfin sistemin diğer bölümlerinde de bu şekilde görülebilmesi önemlidir. UTF bu konuda iddialı ama henüz uygulamada aksayan çok şey var.
Sayısal alanlar ise bu durumdan nokta ve virgül (bin ve decimal ayıracı) ile etkilenmektedir. Veritabanına birkaç yöntemle veri gönderebilir ve yine birkaç yöntemle alabilirsiniz. Doğrudan bir DML komut gönderdiğinizde, server ve kendi sisteminizdeki ulusal ayarları bilmeniz gerekir zira gönderdiğiniz alan ne olursa olsun karakter katar içinde gidecektir. Sunucu bunu alıp analiz ettiğinde virgül e ne anlam yükleyecek bilemezsiniz. Bunun yerine dönüşümleri sizin adınıza yapması için iletişim katmanından yardım alamak daha akıllıca olacaktır. Binary decimal notasyon tek olduğu için, bu katman bilgiyi iki taraflı dönüştürebilir. Delphi ile kullanacağınız komponentler sayısal alanları sistemin ayarlarından aldıkları bilgi doğrultusunda nokta virgül notasyonunda gösterebilirler. Fakat bu sizin bu bileşenlerin içeriğini bir sql e koyup gönderebilmenize olanak sağlamaz. Zira dönüşümün ters yönünü de sizin yapmanız gerekecektir. Veritabanı için aslında bir tek karakter önemlidir decimal ayıraç olan değer. Bu ise yukarıda da dediğim gibi istemci tarafındaki değer olmayabilir. Bu topiğin başlangıcında anlatılan olay tam olarak bu duruma işaret ediyor. Stored procedure ile bulunan çözümde parametreler sayısal olarak gönderildiği için dönüşüm iletişim katmanında çözümlendiğinden sorun yaşanmamıştır. Şayet SQL i doğrudan gönderip o string i sp içinde execute ederseniz aynı sorun yine olacaktır.
Sona doğru biraz dağıldı ama durum budur. 4GL dillerde bu dönüşüm daha abartılıdır zira SQL istemci tarafında oluşur analiz edili ve aradaki katman gereken düzenlemeyi yapıp sunucuya öyle gönderir. Bu nedenle geliştiriciler bu gibi işlerle ilgilenmezler.
--- EK ---
Şayet doğrudan SQL oluşturmuyor ve DB bileşenleri kullanıyorsanız sizin adınıza bu işi kimin yaptığını merak ediyor olabilirsiniz. Şayet bir ODBC sürücü kullanıyorsanız ilk bağlantıda sunucu locale bilgilerini alıp kendisine gelen SQL isteğini sunucunun anlayacağı şekle dönüştüren bu sürücüdür. Yok doğal bir sürücü kullanıyorsanız bu kez de bu sürücü bu dönüşüm ve SQL oluşturma işini üstlenir. Böylelikle sunucuya aslında hep normalize edilmiş saf SQL ler gelir. Gerçekte SQL olmayan db lere yazarken zaten bir SQL oluşturulmaz db ye erişen bileşen onu alır uygun şekilde kaydeder zira bunlarda sunucu yoktur..
Kolay gelsin,
Doğan Zorlu, İzmir
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)
doğan bey elinize sağlık çok açıklayıcı yazmışsınız olayı,
ben eönce sql komutları ile işlemi yapmaya çalıştım fakat sonuçta virgül ve noktadan kaynaklanan sorunlar yaşadım, aynı değerleri stored procedüre ile yapınca problem halledilmiş oldu, sizce benim yaptığım uygulama doğrumu dur veya networklerde problem çıkarırmı ?
saygılar selamlar
ben eönce sql komutları ile işlemi yapmaya çalıştım fakat sonuçta virgül ve noktadan kaynaklanan sorunlar yaşadım, aynı değerleri stored procedüre ile yapınca problem halledilmiş oldu, sizce benim yaptığım uygulama doğrumu dur veya networklerde problem çıkarırmı ?
saygılar selamlar
-
doganzorlu
- Kıdemli Üye
- Mesajlar: 395
- Kayıt: 22 Tem 2004 09:15
- Konum: İzmir
- İletişim:
Selam,
SQL i doğrudan çalıştırmaya neden ihtiyaç duyduğumuzla ilgilidir aslında işlem. Batch işlemleri sp ler aracılığıyla yaparız. RI stabilitesi için triggerları kodlarız ve constraint ler kullanırız. Bu işlemlerin dışında doğrudan SQL çalıştırma ihtiyacı duyuyorsanız tasarımı gözden geçirmek gerekir. Sizin ilk verdiğiniz örnekteki işlemi normalde trigger aracılığıyla yapmanız gerekir. X bir tabloya bir kayıt yazıldığında ilişkili tablolarda yapılacak düzenlemeleri insert/update/delete triggerlarında kodlamanız ve tetiklenme işini de bu sayede otomatik olarak sağlamanız gerekir. Herzaman söylediğim birşey var: "İyi tasarlanmış bir veritabanı, herhangi bir uygulama yazmadan bir SQL interpreter aracılığıyla bile bilgi girdiğinizde/düzelttiğinizde/sildiğinizde stabilitesini kaybetmeyen veritabanıdır". Modelin test edilmesi diye sıklıkla tekrarladığım işlem, bu söylediğim koşulun yerine gelip gelmediğinin kontrolünden ibarettir. Bu anlamda bir soyutlama yapılmalıdır. Örneğin bir kasa kaydını nerden yaparsanız yapın db gereken bağlantılı işlemleri otomatik yapabilmelidir. Yani veritabanınız kendi içinde bir çeşit yapay zeka barındırmalı, sizin kontrolünüz olmadığı durumlarda da stabilitesini koruyabilmelidir. Bu sizi kendinizden de koruyacaktır.
Kolay gelsin,
SQL i doğrudan çalıştırmaya neden ihtiyaç duyduğumuzla ilgilidir aslında işlem. Batch işlemleri sp ler aracılığıyla yaparız. RI stabilitesi için triggerları kodlarız ve constraint ler kullanırız. Bu işlemlerin dışında doğrudan SQL çalıştırma ihtiyacı duyuyorsanız tasarımı gözden geçirmek gerekir. Sizin ilk verdiğiniz örnekteki işlemi normalde trigger aracılığıyla yapmanız gerekir. X bir tabloya bir kayıt yazıldığında ilişkili tablolarda yapılacak düzenlemeleri insert/update/delete triggerlarında kodlamanız ve tetiklenme işini de bu sayede otomatik olarak sağlamanız gerekir. Herzaman söylediğim birşey var: "İyi tasarlanmış bir veritabanı, herhangi bir uygulama yazmadan bir SQL interpreter aracılığıyla bile bilgi girdiğinizde/düzelttiğinizde/sildiğinizde stabilitesini kaybetmeyen veritabanıdır". Modelin test edilmesi diye sıklıkla tekrarladığım işlem, bu söylediğim koşulun yerine gelip gelmediğinin kontrolünden ibarettir. Bu anlamda bir soyutlama yapılmalıdır. Örneğin bir kasa kaydını nerden yaparsanız yapın db gereken bağlantılı işlemleri otomatik yapabilmelidir. Yani veritabanınız kendi içinde bir çeşit yapay zeka barındırmalı, sizin kontrolünüz olmadığı durumlarda da stabilitesini koruyabilmelidir. Bu sizi kendinizden de koruyacaktır.
Kolay gelsin,
Doğan Zorlu, İzmir
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)