В IBProvider, кучу лет назад, было добавлено расширение для запросов с RETURNING, позволяющее явно указывать имена для OUT-параметров.
В процессе перетряхивания связанного кода появилась мысль — можно еще добавить поддержку «RETURNING … INTO_ROWSET …», которая будет возвращать OUT-параметры в виде результирующего множества.
Будем думать…
В новом триале исправлена очень старая бага в коде формирования содержимого колонки PROCEDURE_DEFINITION схемы метаданных PROCEDURES. Провайдер учитывал диалект подключения вместо диалекта базы данных. В результате неправильно обрабатывал имена, требующие квотирования, в подключении с первым диалектом к базе с третьим диалектом.
UPD. [2017-07-16] Сборка ушла в релиз.
Вот так проснешься утром, проверишь почту, а там:
Adriano dos Santos Fernandes:
It seems important to (also) run the tests with the debug build.
У меня такое уже один раз было. Надо еще раз проснуться.
На днях в почту упало письмо с вопросом — «продолжаем ли мы заниматься связкой MSSQL и Firebird?».
Ответил положительно.
Сегодня вот, наконец-то, добавил в статью про Firebird и MSSQL 2012 описание поддержки DEFAULT-значений, которая появилась в последних обновлениях провайдера.
Сегодня сайты ibprovider.com и firebirder.ru переехали на новый сервер.
UPD (2018-06-21). Прикрутили https к обоим сайтам. У Билайна в отношении ibprovider.com продолжает тупить dns и он смотрит на старый сервер. IP нового сервера — 144.76.6.123.
Обновил сборки всех компонент, отгружаемых пользователям.
ADO.NET провайдер v1.7.2.3437
Самым интересным аспектом этого обновления является привязка к инструментальной библиотеке (lcpi.lib, 2.1.1.1665) от предыдущего обновления . В дистрибутивы также включены бинарники и PDB из предыдущего обновления.
Это отработала самописная спец. приблуда процесса формирования дистрибутивов и nuget-пакетов, которая увидела, что версия lcpi.lib не поменялась и подсунула старые модули из спец. хранилища.
В общем, процесс построения дистрибутивов и пакетов ADO.NET провайдера стал более чем нетривиальным. Но полностью автоматизированным — на входе исходники, на выходе MSI, EXE, NUPKG.
(далее…)
С пятницей!
Неделю назад запустил окончательное тестирование своего триллиона битиков оперативной памяти — самую большую группу тестов основной тестовой системы IBProvider-а (blob*). Их там 6713994 штук. В десять потоков. База на RAM диске (80GB).
Не знаю как оно закончится.
Но уже сейчас можно сказать — поставлен своеобразный рекорд, недостижимый на моем предыдущем десктопе с Q6600/8GB.
Проехало 3.7 млн тестов.
Один раз комп ложился баиньки на несколько часов — отключали электричество.
Ошибок нет. База опухла до 38.6GB.
Статистика базы выглядит так:
Database "D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB"
Gstat execution time Fri May 25 15:27:30 2018
Database header page information:
Flags 0
Generation 11273707
System Change Number 0
Page size 16384
ODS version 12.2
Oldest transaction 11272850
Oldest active 11272851
Oldest snapshot 11272838
Next transaction 11272867
Sequence number 0
Next attachment ID 11219
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Apr 18, 2018 23:07:38
Attributes
Variable header data:
*END*
Gstat completion time Fri May 25 15:27:30 2018
FB 3.0.4.32972 SS x64 (Windows).
IBProvider — 3.50 x64.
Через неделю будет окончательный диагноз 🙂
Не приходя в сознание, запилил каркас провайдера для EntityFrameworkCore, через который получилось выполнить по настоящему интересную штуку:
public static class Test_001
{
public class MyContext:DbContext
{
public DbSet<DUAL> table_DUAL { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseLcpiOleDbFirebird
("provider=LCPI.IBProvider.3;"
+"location=inet4://localhost/d:\\database\\ram\\ibp_test_fb30_d3.gdb;"
+"user id=GAMER;"
+"password=vermut;"
+"dbclient_type=fb.direct;"
+"auto_commit=true");
}//OnConfiguring
[Table("DUAL")]
public class DUAL
{
public int ID { get; set; }
};//class DUAL
};//class MyContext
[Test]
public static void Test_01()
{
using(var db=new MyContext())
{
foreach (var rec in db.table_DUAL)
{
Console.WriteLine("ID: {0}",rec.ID);
}
}//using
}//Test_01
};//class Test_001
Теперь можно включать спинной мозг для дополнительной разведки местности.
И мне уже кажется, что UseLcpiOleDbFirebird нужно сократить до UseLcpiOleDb. Потому что, скорее всего получится соорудить универсальный провайдер как для Firebird, так и для InterBase.
Привет всем.
С сайта IBProvider и с nuget.org можно загрузить обновленный ADO.NET провайдер — v1.7.
Изменения минимальны — синхронизация с поведением текущей версии IBProvider v3.50 в плане кодов ошибок. Плюс немного доработаны тесты.
В остальном — все без изменений. Пока в этом нет никакой необходимости.
—
Полтора года назад разочаровался в EF v6. Это реально адское поделие жителей Индии.
Теперь вот linq2db разочаровал — у него какая-то корявая работа с провайдерами. Два месяца на него убил.
Осталось посмотреть EF.Core.
Привет всем.
1. Сегодня наконец-то снова загрузился в Windows со 128GB на борту. Шесть Семь месяцев долбежа (хотя по ощущениям — прошла бесконечность). Будем посмотреть.
Из радикальных изменений — отключил HT у процессора. При компиляции в 20 потоков эпизодически вылазил синий экран. На msdn ищите «Перегружается компьютер 6950x» (нашел, сейчас открывается только в Edge).
По «железу» добавлю еще то, что (похоже) из-за фрагментации диска может вылазить другая проблема с компиляцией, которую я описал здесь.
2. Залез под ногу монитора, где лежит бумажка с проклятьями приветами из прошлого. Последняя запись от 2017-09-02 с печалью по поводу необходимости перетряхнуть 3MB исходного кода на C++. На это ушло 8 месяцев, что согласуется с производительностью 4MB/год.
Значит, я еще пока в форме 🙂