Re: Выходной формат запросов isql
А чего бы прям в Excel не данные не загружать? Его же средствами импорта данных :-) xls тоже вполне просто. :) И для реализации Excel IRTDServer примерчик со стандартным для винды пакетом PyWin32 идёть. Так шта можно и в ральном времени :D Ну типа круто :-) Интересно, какое соотношение по времени будет между протаскиванием данных через провайдер-ADO и твоё сооружение? :-))) Про то, что у тебя не все типы данных можно будеть (безболезненно) протащить, я типа вслух промолчу. Угыгы. Коваленко Дмитрий.
Re: OFF: Дисковый кешь
Hello, Leonid Leonid wrote: Я сразу извиняюсь, что не по теме. Но просьба проконсультировать. Сервер HP DL380G5 Предназначен под базу данных на FireBird. Пять дисков включены в 5-й рейд. При настройке самого рейда все нормально. После установки Windows дисковый кешь по умолчанию выключен. Я его включаю в свойствах диска. (Device Manager - Disk Drives - HP LOGIKAL VOLUME...- Properties - Policies) черт подери! Извиняюсь за эмоциональность, но зайдите на hp (или чей контроллер) и скачайте СОФТ для управления Вашим контроллером. Без софта подобные опции действуют например только для обычных дисков на десктопах. Представитель от HP не моргая утверждает, что так и должно быть и что кешь при этом работает. Как проверить работает кешь или нет? Или все неправильно? это все лабуда, пока не установите указанный софт. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Выходной формат запросов isql
Kovalenko Dmitry пишет: Интересно, какое соотношение по времени будет между протаскиванием данных через провайдер-ADO и твоё сооружение? :-))) Думаю ежели для целей анализирования подойдёт импортперетаскивание через csv, то не думаю что это соотношение будет как-то критично. :) Про то, что у тебя не все типы данных можно будеть (безболезненно) протащить, я типа вслух промолчу. Угыгы. Да, думаю массивы не пролезут (надать как-нибудь проверить). Но их и не очень понятно как в Ёксель, для анализировать, запихуевать. :) -- Александр Замараев
Re: Выходной формат запросов isql
Интересно, какое соотношение по времени будет между протаскиванием данных через провайдер-ADO и твоё сооружение? :-))) Думаю ежели для целей анализирования подойдёт импортперетаскивание через csv, то не думаю что это соотношение будет как-то критично. :) Про то, что у тебя не все типы данных можно будеть (безболезненно) протащить, я типа вслух промолчу. Угыгы. Да, думаю массивы не пролезут (надать как-нибудь проверить). Но их и не очень понятно как в Ёксель, для анализировать, запихуевать. :) Не, массивы это само собой. Хотя VBA (да и вообще, VB) с SAFEARRAY (если мне не изменяет память) работает зер гуд. Это в VBS - сплошной ахтунг. Я в последнее время замарачивался на разношерстных кодовых страницах (включая ICU) в одной БД. И NONE-подключении. Сценарий из категории Превед Медвед. Но такое стоит делать только на FB и только на 2.5. И желательно в противогазе : --- Масштабирование загружаемых нумериков у вас там как обрабатываются - небось через double? :-) Коваленко Дмитрий.
Re: Выходной формат запросов isql
Kovalenko Dmitry пишет: Я в последнее время замарачивался на разношерстных кодовых страницах (включая ICU) в одной БД. И NONE-подключении. Там можно подсунуть свои способы перекодировок. По умолчанию или для конкретных полей. :) Масштабирование загружаемых нумериков у вас там как обрабатываются - небось через double? :-) Вот щас. Через decimal.Decimal - класс чисел с фиксированной точкой. :) П.С. Вообще драйвер очень грамотно сделан. По крайней мере с точки зрения пользователя. :) -- Александр Замараев
Re: Выходной формат запросов isql
Гы, ну никак подловить не удается :)) П.С. Вообще драйвер очень грамотно сделан. По крайней мере с точки зрения пользователя. :) Дык. На сколько я в курсе его же, вроде, в родной тестовой системе FB юзают? Что то мне кажется, что драйвер не может быть _очень_ граммотно сделан :-) Хорошо сделан - поверю. Для каких-то конкретных сценариев. А очень - вряд ли. Это слишком дорого. Там только на одной обратной совместимости - рехнешься :-) И некоторые вещи надо обрабатывать на клиенте. Для того что бы они правильно работали. А питонский драйвер - это по-моему чистый транслятор вызовов ISC API. Без заморочек выполнит работу любой ценой в любых условиях :-) Он же по-моему до сих пор завязан на ibase.h (вот уж действительно реальное публик API) и статически линкуется с DLL клиента? Если я все правильно, напутал читая в девеле ветку с обсуждением устаревшей isc_interepret. Хотя, кажется Влад(?) говорил, что его собираются совсем оторвать от клиента и сделать по образу и подобию нет-провайдера. Коваленко Дмитрий.
Археология. BIGINT и IB6.5
Привет всем. Берем базу от FB1.0 (ODS10.0) Подсовываем под FB1.5 Создаем колонку с типом BIGINT. Создается без проблем. IBE говорит про неё тип BIGINT Возвращаем базу обратно под FB1 IBE говорит что колонка все тот же BIGINT. Хотя, в FB1 нет такого типа. Ok. Подсовываем эту базу под IB6. IBE снова говорит, что тип колонки - BIGINT Ладно, с IBE все понятно. --- Но я вот что думаю. Формально надо было в FB1.5 не позволять создавать BIGINT колонки для неродного ODS. Только для ODS10.1 --- Кстати, вот еще. По поводу http://www.ibase.ru/devinfo/prevver.htm Там нет IB6.5. У него ODS10.1. Полуторка может подключаться к базам IB6.5. И наоборот. Хотя, конечно, так работать не следует :) --- Коваленко Дмитрий.
