Błąd 07006 czyli Naruszenie atrybutu ograniczonego typu danych podczas dostępu do rekordu dbo.Faktury

I z rozpędu kolejny babolik własnej produkcji:

Pojawia się wtedy gdy próbuję użyć {prop:sql} na strukturach gdzie liczba/typy/kolejność kolumn w dct różnią się od tego co jest w SQL. W tym przypadku zrobiłem małe sprzątanie w dct, a sql-owe odłożyłem sobie na ” jak będę miał większe moce przerobowe”.

Zapomniałem jednak, że kiedyś pod wpływem „eksplozji chęci bycia cool, maczo programowania itd” popełniłem taki kod:

faktury{PROP:SQL} = 'select * from faktury where ....

loop until Access:Faktury.Next()
...
...

…i dopóki dct było zgodne z SQL, to ten trik dawał ogromny zysk wydajnościowy, a jednocześnie był miną przeciw-programistyczną na którą zgodnie z prawem Murphy’ego, się nadziałem. I taką został – posprzątałem w SQL.

Błąd (01S01) co to za błąd? Szczególnie z punktu widzenia programisty Clarion

Od czasu do czasu, po kolejnym grzebnięciu w kodzie pojawiają się dziwne komunikaty błędów. Praktycznie za każdym razem przypominam sobie, że miałem z czymś takim do czynienia, że znalazłem rozwiązanie, ale już nie pamiętam. Następuje proces przeszukiwania Google, który jak zwykle charakteryzuje się tym, że niby tematów podobnych jest mnóstwo, ale to tylko takie „akademickie” pitolenie, z którego niewiele wynika.
Najchętniej znalazłbym własną odpowiedź: jak sobie poradziłem poprzednim razem. I temu służy ten wpis.

Błąd (01S01) czyli SQL fractional truncation, występuje w przypadku moich programów gdy pobieram typ DATE (w dct) z SQL gdzie jest on DateTime i w cześć bitów zawierającej Time są wartości rożne od 0. Najczęściej występuje to wtedy gdy dokonam update tej daty w SQL np funkcja getdate(), bez przycięcia części związanej z czasem:
Wtedy wystarczy zwykły update:

update[RejestrZdarzen]
set data = cast(cast(data as int) as datetime)
where data <> cast(cast(data as int) as datetime)

i pozamiatane. Oczywiście można dyskutować , że skoro w SQL jest DateTime, to w DCT tez tak powinno być, ale to rozwiązanie ma też kilka wad, które irytują mnie niekiedy bardziej niz powyższe.

Okazuję się, że w przypadku samego pola typu Time w clarionie, w SQL po konwersji np FM3 to pole tez jest DateTime i tez jest mały problem bo SQL potrafi zapamiętać tam więcej niż clarion, co w konsekwencji też wywoła powyższy błąd w aplikacji clarionowej.

prostowanie polega na wycięciu części z tysiecznymi np tak:

update[RejestrZdarzen]
set czas = cast(czas as char(19))
where ...

Może się jednak przekonam na używanie grup DateTime …