Delphi Can

Orjinalini görmek için tıklayınız: Önermiyorum - 5 (INT > BIGINT)
Şu anda (Arşiv) modunu görüntülemektesiniz. Orjinal Sürümü Görüntüle internal link
Ek'teki resimlerde görebileceğiniz gibi MySQL'in bir başka aptal tarafına tesadüf ettim.

Bir tablo içinde INT olarak tanımlı bir alanınınız var ise ve bu alan NULL olabiliyor ise; bu durumda NULL ise 0 (Sıfır) olsun dediğiniz SP'lerinizden artık INT türünde bir alan değil, BIGINT türünde bir alan dönecek. Dolayısı ile eğer Delphi tarafında o field'ı INT olarak eklediyseniz hata alacaksınız.

Ayrıca çok detaya girmeye gerek duymuyorum ama, "Ey gafil MySQL sen ne demeye 4 byte'a sığacak bir data için fazladan 4 byte daha yer açarsın, kime sordun ?" diye sormayı da ihmal etmem.

MySQL kullanan ve kullanacakların Allah yardımcısı olsun.

Bu soruna çözüm önerisi ise daha da komik. Diyorlar ki: "INT değer döndüren bir dummy function yapın ve BIGINT datayı bu fonksiyona parametre olarak geçin sonra da Result'a eşitleyin. Kısaca casting yapın."

Ancak bunun için zaten hali hazırda mevcut olan 2 adet fonksiyon (CAST ve CONVERT) maalesef BIGINT veritürünü INT veri türüne çeviremiyor.!

Gülsem mi ağlasam mı karar veremedim ben  Undecided
Doğru.

Bu durum sadece Integer veri tipinde gerçekleşmiyor, benzer bir şekilde tinyblob, blob, mediumblob, Longblob veri türlerini TEXT ve VARCHAR gibi veri türlerine dönüştürdüğüne de şahit oldum...

BLOB ve türevlerinden parça halinde veri çekmek için şunun gibi bir fonksiyonla problemi çözdüm ama işte. Olduğu kadar...
CREATE DEFINER=`falanca`@`filanca` FUNCTION `sm_fn_partblob`(
 `aSource` ENUM('sm_documents_blob','sm_sys_guncelleme_blob','sm_dokumanlar_blob'),
 `aRef` INT,
 `aPageNo` INT,
 `aSize` INT
)
RETURNS longblob    /* <-- BU SATIR SAYESİNDE SORUN ÇÖZÜLDÜ */
LANGUAGE SQL
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
 DECLARE  P INT;
 SET P = (aPageNo * aSize) + 1;
 IF      (aSource = 'sm_documents_blob') THEN      RETURN (SELECT SUBSTRING(BLOBDATA, P, aSize) FROM sm_documents_blob       WHERE   Ref = aRef LIMIT 1);
 ELSEIF (aSource = 'sm_dokumanlar_blob') THEN      RETURN (SELECT SUBSTRING(Veri    , P, aSize) FROM sm_dokumanlar_blob      WHERE   Ref = aRef LIMIT 1);
 ELSEIF (aSource = 'sm_sys_guncelleme_blob') THEN  RETURN (SELECT SUBSTRING(BLOBDATA, P, aSize) FROM sm_sys_guncelleme_blob  WHERE Files = aRef LIMIT 1);
 END IF;
END
Aynı (Integer ve Bigint ile ilgili) durum MySQL'in devamı niteliğindeki MariaDB'de de devam ediyor mu diye test ettiğimde bu durumla karşılaşmadım. BLOB'lar için ayrıca test etmek gerek.
bu arada kullandığınız mysql versiyonu nedir ve community/enterprise
Hatta sırf bu yüzden , MyDAC bileşenlerinde "Data Type Mapping" adı altında bir özellik mevcut, özetle şöyle diyorsunuz, databaseden INT gelirse TIntegerField yap , BIGINT Gelirse de TIntegerField yap, bu sayade Dataset in FieldListine tasarım anında eklediğiniz TIntegerField, DB den BIGINT döndüğünde de INT döndüğünde de uyumlu bir şekilde çalışacaktır.
(01-01-2019, Saat: 14:36)masteryoda Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.bu arada kullandığınız mysql versiyonu nedir ve community/enterprise

MySQL Community, 8 kullanıyorum.
(02-01-2019, Saat: 08:40)vkamadan Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.Hatta sırf bu yüzden , MyDAC bileşenlerinde "Data Type Mapping" adı altında bir özellik mevcut, özetle şöyle diyorsunuz, databaseden INT gelirse TIntegerField yap , BIGINT Gelirse de TIntegerField yap, bu sayade Dataset in FieldListine tasarım anında eklediğiniz TIntegerField,   DB den BIGINT döndüğünde de INT döndüğünde de  uyumlu bir şekilde çalışacaktır.

MyDAC için Field Mapping güzel bir özellik ama bu sadece ekstra bir özellik ve üçüncü parti bir firmanın ürünü Volkanım. Esas olması gerekeni MYSQL tarafında yapmamış adamlar. Benim INT alanım neden BIGINT'e çevrilir hem de basit bir NULL kontrolü sırasında, esas soru bu !

Herneyse maksadımız; bu kendisine ilişkisel veritabanı diyen zımbırtıya yeni başlayacak birileri var ise bu konuları o arkadaşlar okusunlar ve dikkatli olsunlar. Yoksa ne Microsoft'ta ne de ona benzer bir yerde çalışıyorum Smile
(01-01-2019, Saat: 13:40)uparlayan Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.Aynı (Integer ve Bigint ile ilgili) durum MySQL'in devamı niteliğindeki MariaDB'de de devam ediyor mu diye test ettiğimde bu durumla karşılaşmadım. BLOB'lar için ayrıca test etmek gerek.

Bu güzel bir haber nispeten, teşekkür ederim. Bu bölüm altında MySQL hakkında bahsettiğim olumsuz davranışların MariaDB tarafındaki durumlarını kontrol etmenizi istirham etsem çok mu şey istemiş olurum ?
Estağfurullah, tabi, zaten benim de kullandığım bir veritabanı, karşılaştığım çözümleri ve problemleri fırsat bulduğum nispette buradan paylaşabilirim
Not: MySQL'in bu aptal durumunun etrafından dolanmanın bir yolunu buldum. Paylaşıyorum.

Benim örneğimde ExecutionTimeMs INT türünde ve IFNULL(ExecutionTimeMs, 0) satırında tipi BIGINT olarak değişiyor. Benim uyguladığım çakal yöntemde ise bu değişim olmuyor. Bunun için INT türünde Dummy bir değişken tanımlayıp varsayılan değeri sıfır(0) olarak ayarlanır ve kod aşağıdaki hali alır:

DECLARE
  DummyDegisken INT DEFAULT 0;

  SELECT
    ..,
    ..,
    IFNULL(ExecutionTimeMs, DummyDegisken) AS ExecutionTimeMs

Bu sayede tip değişiminin kontrolünü yine ben ele geçiriyorum. Tek sakıncası değişken tanımlamak.

Aklınızın bir ucunda olsun.