BdpDataAdapter1.SelectCommand.CommandText :='INSERT INTO netsiparis (BARKODNO,MIKTAR) VALUES ('+#39+TEXTBOX1.Text+#39+','+#39+TEXTBOX3.Text+#39+')';
bu kodda textbox3 deki veri 12,56 gibi bir değer girildiğinde veritabına 1256 olarak kaydediyor..küsüratsız değerlerde problem yok zaten.Bu sorunu nasıl aşarım.strtofloat gibi bir şey olabilirmi tabi .net de böyle birşey varsa.
kolay gelsin.
Olmaz . SQL sorgulamada dil kuralı olarak virgül, öğeleri birbirinden ayırmaya yarar. Bunun mantığı ise ondalıklı sayıyı ekranda göstermek gibi değildir kuraldır .
Şaban Şahin AKMAN
_________________ Derin olan kuyu değil kısa olan iptir. - .
string birleştirme ile sql oluşturmak hiç şık ve pratik bir yol değil. Params özelliği yokmu kullandığın bileşende ? Params ile veritipleri ve quote işaretiyle uğraşmazsın. Params yoksa Format fonksiyonu ile stringi düzenlemek daha kolay.
MySQL de de böyle nokta ile ondalık ayraç yapılıyor.Bende Validate edit içindeki değerin virgüllerini nokta, noktalarını da virgül yaparak meseleyi bir fonksiyon ile halletmiştim...
BdpDataAdapter1.SelectCommand.CommandText :=Format('INSERT INTO netsiparis (BARKODNO,MIKTAR) VALUES (''%s'',''%s'')',[TextBox1.Text,TextBox2.Text]);
şeklinde kullanırım .
Tarih, ondalıklı tipler gibi şeyler format fonksiyonu ile işletim sisteminin bölgesel ayarlarına göre biçimlendiriliyor. Firebird mesela biçimlendirmeleri bölgesel ayarlara göre değil kendi standardında istiyorki bence de en iyisi bu. Bölgesel ayarların değişebilirliği yazılımı çalışmaz kılabilir. Bileşen/lib yazarları DB için neyin lazım olduğunu daha iyi bildikleri için onların varianttan dönüşüm yapma fonksiyonlarına güvenmek en iyisi olacaktır. Variant burda sadece veriyi tutuyor, önemli olan dönüşümü. Ayrıca parametre kullanıldığında bunlar muhtemelen stringe dönüşmüyor, db'nin istediği binary formata dönüşüyor. Ayrıca parametreli Sql çalışmadan önce prepare olabiliyor.
Kesinlikle haklısınız. Tarih sorgulamalardaki veritabanı ayarları sorun çıkarabilmektedir ve bu da veritabanı connection bileşeninin AfterConnect olayında (SQL Server için) set dateformat dmy gibi bir kodla tüm sorgular gün.ay.yıl biçimine göre çalışmaktadır. FB içinde benzeri bir ayarlayıcı kod vardır diye tahmin ediyorum. Buna "yoğurt yeme stilleri faklı!" deniyor olsa gerek . Aslında parametreli SQL sorguların daha pratik olduğunu kabul ediyorum ama projelerimizdeki tasarımlara göre verilen where şartı yapısal değişiklik gösterdiğinden tüm sorgularımızda hep bu şekilde yapmaya alışmışız artık .
Şaban Şahin AKMAN
_________________ Derin olan kuyu değil kısa olan iptir. - .
yani işin içinde win32 programlama olsaydı zaten bir şekilde hallolurdu..Tabi daha işin acamisiyiz ama sanırım webaplication olaylarında bu kadar takla attıramıyoz..Aslında performans kaygılarımda var yani kullanıcı virgül yazar kayıttan önce virgüller noktaya çevrilip fonksiyonla öyle kaydedilir ama sitenin performansı nolur bu fonksiyonları client mi işler yoksa servermı işler clientler zaten el terminali olacak o yüzden en az ve en standart kodlama biçimiyle yazmak lazım diye düşünüyorum.
serkan yazdı:Aslında performans kaygılarımda var yani kullanıcı virgül yazar kayıttan önce virgüller noktaya çevrilip fonksiyonla öyle kaydedilir ama sitenin performansı nolur bu fonksiyonları client mi işler yoksa servermı işler
Performansa hissedilir düzeyde bir etkisi olmaz (bence hiç etkisi olmaz). Server çalışır elbette, başka istisna var mı bilmiyorum ama java script kodları haricinde diğer komutlar server tarafında işler.