Custom Query (429 matches)
Results (28 - 30 of 429)
|#286||fixed||Dual MySQL queries don't work as expected|
-------------------------------- -- Pooled_Database.Test_Alive -- -------------------------------- function Test_Alive (Object : not null access Pooled_Database_Object) return Boolean is Q : SQL.Queries.SQL_Query; Eight_Value : Holder; begin Q := Object.Query (From_UTF_8_String ("SELECT 3 + 5 AS eight")); Q.Execute; Eight_Value := Q.Value (1); Ada.Text_IO.Put_Line ("Test_Alive received" & Integer'Image (League.Holders.Integers.Element (Eight_Value))); return League.Holders.Integers.Element (Eight_Value) = 8; exception when E : SQL_Error | Constraint_Error => Ada.Text_IO.Put_Line ("While Test_Alive... " & Ada.Exceptions.Exception_Name (E)); return False; end Test_Alive;
Test_Alive received 0
I have yet no idea what is exactly going on here. I can't spot any obvious explanation.
Version: 0.4+ [r3727] vadim.godunko: Make Has_Detail abstract. Declare all kinds of faults as
|#300||fixed||cp1251 and alike names should be supported|
Programs compiled with League raise Constraint_Error without any clear reason. Exception can't be handled in main body, no meaningful symbolic traceback can be seen. Investigation shown that VPS setting is LANG=ru_RU.cp1251 and it breaks League initialization.
|#308||fixed||League.Calendars.Ada_Conversions is incorrect|
I have recently run into situation where current method of date/time conversion doesn't work. AWS creates date/time out of HTTP date in a wrong way. Ada has special APIs for time-zone conversions including UTC, but AWS instead creates date/time as if it were a local date/time. As result, I've got an Ada date/time value that can't be accepted by Matreshka conversion because Seconds / 3600 = 24 > 23
Response header Date: Fri, 07 Jun 2013 23:36:43 GMT Seconds = 85003.00000000
I think, a better option for Matreshka is to use Ada.Calendar.Formatting APIs for conversions. They explicitly have a time-zone argument that defaults to 0, and they have distinct hour/minute/secons/subsecond/leapness arguments.