Re: Диапазоны PK для филиалов
Переделывая на новую версию: удаляю старые PK с одним полем ID, создаю новые PK с двумя полями ID и IDBASE. Но как теперь сделать FK? Что-то я не понял, а какие тут проблемы с FK ?
Re: Диапазоны PK для филиалов
Вобще-то лично мне составные FK не нравятся по некоторым соображениям. Я
все таблицы делаю по такому вот шаблону:
CREATE TABLE "_MyTable" (
"Id" "GlobalId" NOT NULL PRIMARY KEY /* "GlobalId" =
BIGINT NOT NULL */,
"LocalId" "LocalId" /* "LocalId" = INTEGER NOT NULL */,
"InstanceId" "InstanceId" /* "InstanceId" = SMALLINT NOT NULL */,
UNIQUE ("LocalId", "InstanceId")
);
CREATE TRIGGER "_MyTable_BIU0" FOR "_MyTable"
ACTIVE BEFORE INSERT OR UPDATE POSITION 0
AS
BEGIN
IF (INSERTING) THEN
BEGIN
IF (NEW."LocalId" IS NULL) THEN
NEW."LocalId" = GEN_ID("GenMyTableId", 1);
IF (NEW."InstanceId" IS NULL) THEN
SELECT CAST("Value" AS INTEGER) FROM "GetParameter"('InstanceId')
INTO NEW."InstanceId";
END
ELSE IF (UPDATING AND OLD."LocalId" <> NEW."LocalId") THEN
EXCEPTION "UpdateError" '"_MyTable_BIU0": Íåäîïóñòèìîå èçìåíåíèå
ïåðâè÷íîãî êëþ÷à';*/
NEW."Id" = NEW."LocalId" + 4294967296 * NEW."InstanceId";
END
То есть глобальный ID есть величиной вычисляемой на основании локально
сгенерирированного значения и кода экземпляра базы. Потом на эту таблицу
вешаю соответствующее представление и с этим представлением и работаю.
Там уже полей LocalId и GlobalId нету конечно...
Re: Диапазоны PK для филиалов
Ю> Все просто: был проект с маленьким ТЗ: 1 офис, 1 база, теперь появилась Ю> необходимость поставить ее в нескольких филиалах. Ю> Решил разнести филиалы добавив во все таблицы новое поле IDBASE, но столкнулся с Ю> проблемой FK. Ю> Переделывая на новую версию: удаляю старые PK с одним полем ID, Ю> создаю новые PK с двумя полями ID и IDBASE. Но как теперь сделать Ю> FK? Ю> Чет я туплю по жесткому в пятницу хелп... кто как решал подобную Ю> задачу??? Посмотри в сторону естественных ключей, типа 'IDbase-ID' http://ibase.ru/devinfo/NaturalKeysVersusAtrificialKeysByTentser.html http://www.alexus.ru/russian/articles/dbms/keys/index.htm С уважением, Константин Григорьевич. ===
Re: Диапазоны PK для филиалов
> > Чет я туплю по жесткому в пятницу хелп... кто как решал подобную > задачу??? > если филиалов не очень много, то можно предложить схему с диапазонами ИД. На каждой базе сдвигаете значение генератора на определенную дельту или заводите отдельный генератор для хранения смещения. тогда ИД присваивается как GEN_ID(gen, 1) + GEN_ID(offs, 0)
Re: Диапазоны PK для филиалов
"Andrei" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > если филиалов не очень много, то можно > предложить схему с диапазонами ИД. На Не надо так делать. Гемора больше. PK из двух полей ID, BASE_ID прекрасно работает четыре года на 28 базах + центральный офис. FK на два поля намного проще и надежнее. Если филиалы не должны видеть друг друга, то в филиалах только свое ID без BASE_ID. В центре естественно ID, BASE_ID. Строить отчеты, группировать, да и вообще разводить хитро-мудрую аналитику проще. -- Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: Диапазоны PK для филиалов
A> A> "Andrei" <[EMAIL PROTECTED]> A> сообщил/сообщила в новостях следующее: A> news:[EMAIL PROTECTED] A>> A>> если филиалов не очень много, то можно A>> предложить схему с диапазонами ИД. На A> A> Не надо так делать. Гемора больше. ну так подскажи тогда человеку по FK И еще, поделился бы, как ты при этом репликацию делаешь. -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Диапазоны PK для филиалов
"Alexandr Kochmin" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > ну так подскажи тогда человеку по FK FK - делаем как учили классики. CREATE TABLE TAB1 ( IDINTEGER NOT NULL, BASE_IDINTEGER NOT NULL, .. ); ALTER TABLE TAB1 ADD CONSTRAINT TAB1_PK PRIMARY KEY (ID, BASE_ID); ... CREATE TABLE TAB2 ( . TAB1_ID INTEGER, TAB1_BASE_ID INTEGER, ...); .. ALTER TABLE TAB2 ADD CONSTRAINT TAB2_TAB1 FOREIGN KEY (TAB1_ID, TAB1_BASE_ID) REFERENCES TAB1 (ID, BASE_ID) ON DELETE тра-та-та ON UPDATE ля-ля-ля; > И еще, поделился бы, как ты при этом репликацию делаешь. Эта наша проктология нудная, и мало интересная широкой общественности 8-) Алгоритм описывать - неделя нужна. Если коротко, то в филиалы (у нас аптеки) из центра идут справочники, накладные, остатки склада, выжимки из прайсов поставщиков, категории ассортимента, режимы работы, скидки и еще много всякой всячины. А из аптек в центральный офис - журналы продаж, текущие остатки, дефектура, индивидуальные заказы, информация об акцептах/неакцептах позиций в накладных, проекты возвратных накладных, и т.д. Несколько аптек объединены в отделения. Для зав. отделением поступает та же информация (пройдя через центр), что и в центральный офис, но только по ее/его аптекам. По большому счету это не репликация баз в общепринятом смысле, а всего лишь синхронизация справочников и обмен информацией. Если кому интересно, то отвечу на конкретные вопросы. Просто описывать весь обмен (репликацию) слишком долго, да и не интересно. -- Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: Диапазоны PK для филиалов
A> ALTER TABLE TAB2 ADD CONSTRAINT TAB2_TAB1 A> FOREIGN KEY (TAB1_ID, TAB1_BASE_ID) A> REFERENCES TAB1 (ID, BASE_ID) ON DELETE тра-та-та ON UPDATE ля-ля-ля; A> да, так вот если база уже есть, и без этого, то встроить это в существую базу дюже сложно. A>> И еще, поделился бы, как ты при этом репликацию делаешь. A> A> Эта наша проктология нудная, и мало интересная широкой общественности A> 8-) Алгоритм описывать - неделя нужна. понятно спасибо. -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Диапазоны PK для филиалов
Alexandr Kochmin пишет: да, так вот если база уже есть, и без этого, то встроить это в существую базу дюже сложно. Мы сделали проще - добавили в каждую реплицируемую таблицу по уникальному полю - REPL_ID BIGINT И триггер на инсерт, который заполняет его, если оно NULL. Соответственно, в логике базы ничего менять не пришлось и в приложениях всё осталось как было, а репликация вся именно по этому полю и идёт.
Re: Диапазоны PK для филиалов
"Tonal" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > Мы сделали проще - добавили в каждую реплицируемую таблицу по > уникальному полю - REPL_ID BIGINT > И триггер на инсерт, который заполняет его, если оно NULL. Очень интересное решение. Попробую у себя что-то похожее замутить. Спасибо за совет. -- Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: Диапазоны PK для филиалов
Привет, Константин! Вы пишешь к Юрий 23 декабря 2006: К> Посмотри в сторону естественных ключей... На правах прошедшей пятницы, и по поводу естественных ключей: "О тотальной идиотии в [пост]бюджетных организациях". Рядом с нашей конторой, был когда-то "неблагонадёжный" банк. Хороший ли, плохой ли, история о нём умалчивает. В свете новейших решений партии и правительства, а также в связи с очередной борьбой с чем-то там, банк закрылся. Свято место пусто не бывает. В том же помещении пустил корни СберБанк России... Прохожу надысь окрест оного банка, вижу громадную рекламу: "Переводы БЛИЦ! Мгновенно! По всей России! Без открытия счёта" и т.д. и т.п. А тут как раз, НовоГодие на носу, тёщу любимую, забодай её комар, проздравить нужно, и чем-то эдаким порадовать. Ну а как известно, теща рада больше всего на свете (кроме приезда любимого зятя), конечно же деньгам. Дык вот он же ж банк! Заходи, отправляй! Захожу... Народу никого. Ваааще. Скучающий охранник. Вопрошаю - и где мол? В любую кассу - ответствует. А кассы, как это нонче модно, с отдельными дверцами, чисто как в общественном туалете... Суюсь в одну - занято. В другую - занято! В третью, вы не поверите, тоже занято! Ну ладно, чай не в туалете, можно и потерпеть... Интересуюсь - а чё это народ оттудова не выходит так долго? Отвечают - программное обеспЕченье новое у нас, потому так долго, с непривычки то. Ждём-с... А вот и кабинка освободилась! Не прошло и получаса... Радостный врываюсь в кабинку. - Тётенька, мне перевод послать, тёще любимой... - Кому? - Ивановой. - Вы мне не говорите тут! Я со слов отправлять не буду. Пишите не бумажке. - А где бланки? - Нету бланков, но любой бумажке пишите. ...возникают ассоциации с туалетной бумагой, но, гоню их прочь... - Написали? - Угу. Вот. - Данные паспорта! - Вот мой паспорт. - Не ваш. - Что значит не мой?! - Данные паспорта человека, который будет получать деньги! ...пля-а-а-а-а... - Откуда ж я знаю данные паспорта тёщи моей любимой, комар её забодай?! - Без данных нельзя! - Почему??? - У нас система так построена, перевод идентифицируется ПО НОМЕРУ ПАСПОРТА. И вот тут у меня случился приступ истерического хохота... Больше в СберБанк я не хожу. Боюсь лопнуть от смеха. ЗЫ: публикуется впервые. -- With best regards, Alex Cherednichenko.
Re: Диапазоны PK для филиалов
AC> - У нас система так построена, перевод идентифицируется ПО НОМЕРУ AC> ПАСПОРТА. Неужели правда? Ужась. -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Диапазоны PK для филиалов
"Alex Cherednichenko" ... > На правах прошедшей пятницы, и по поводу естественных ключей: > > "О тотальной идиотии в [пост]бюджетных организациях". Теща читает этот форум ? :) -- Хорсун Влад
Re: Диапазоны PK для филиалов
А чем не хватает типа BIGINT? Мы как-то решали такую проблему, как бы так обеспечить ее родимую репликацию данных между филиалами. Сначала конечно подумали про GUID .. Подумали дальше про диапазон значений... до сих пор вроде бы хватало INTEGER для полей 19 значащих цифр, не уверен на счет IB -9223372036854775808 (java.lang.Long.MIN_VALUE) +9223372036854775807 (java.lang.Long.MAX_VALUE) берем пару старших цифр и отводим под филиал, 99 филиалов хватит за глаза, а если и не хватит то 999 хватит точно ... остается для каждого филиала достаточная цифра 3372036854775807 ... взглянув на эту цифру вообще сделали один генератор на всю базу ставишь первый филиал стартовое значение этого генератора 001 ставишь второй 002 -- С наилучшими пожеланиями, Николай Войнов.
Re: Диапазоны PK для филиалов
Люди, напишите еще что-нибудь. Когда читаешь ответы на эту тему, депрессия как-то нет так сильно давит на моск. Коваленко Дмитрий.
Re: Диапазоны PK для филиалов
KD> Люди, напишите еще что-нибудь. KD> KD> Когда читаешь ответы на эту тему, KD> депрессия как-то нет так сильно давит KD> на моск. KD> Дима, не все могут позволить себе такую рокошь, как написание репликации объектов - документов. ;) Остальные вот так и мучаются. -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Диапазоны PK для филиалов
"Kovalenko Dmitry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Люди, напишите еще что-нибудь. Чти ветку приколы
Re: Диапазоны PK для филиалов
On Mon, 25 Dec 2006 14:46:51 +0300, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote: > Люди, напишите еще что-нибудь. Только для тебя ;) Вставлю свою 1 копейку критики. Andrei, разделение на диапазоны - плохая идея, не только из-за тонкостей реализации. Ты жёстко закладываешься на "если филиалов не очень много". Если они уже есть, то их будет больше. А если один "разрастётся" и вылезет за свой диапазон? ArtGal, PK из двух полей работает, всё верно, но это всё равно не лучшая идея. Попробуй мне объяснить необходимость лишнем сегменте индекса? Да, в "отчётной" базе, где всё свалено, там даст небольшой прирост в "мультибазовых" запросах. Но так в ней можно свой индекс сделать, как раз для этих задач, и совсем не PK. Включать сюда ещё и ссылочную целостность вообще не ясно зачем. Целостность она хороша внутри замкнутой структуры, а именно одной базы. Никакой твой FK не ссылается на объект другой базы, разве нет? А если нет, то зачем так делаешь? Tonal, не догнал, чем тебе помогло отдельное поле REPL_ID. Всё равно решение задачи уникальных ID не описано. И что мешает вместо REPL_ID использовать собственно PK ID из этой же таблицы, формируя её по тем же принципам, что и REPL_ID? Свой решение вижу так - PK, как и ID - одно поле, уникальное внутри одной базы/таблицы, FK ссылается на это "однополенное" ( :D само так написалось ) ID, храня целостность внутри базы. Для репликации есть дополнительное поле, а именно BaseID, но оно в PK не входит. Индексировано оно только в "слитой" базе. -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
Привет, Варакин! Вы пишешь 25 декабря 2006: >> - У нас система так построена, перевод идентифицируется ПО НОМЕРУ >> ПАСПОРТА. ВН> ну то что какая-то там тетенька чего то ляпнула еще не значит что так оно и есть. ВН> а вообще я еще не встречал систем быстрого перевода которые не требовали бы ВН> паспортных данных. Получателя?! Да ты эээ... перегрелся! Никто не требует. ФИО получателя, да, требуется. И то, не всегда. Но требовать от ОТПРАВИТЕЛЯ знание номера паспорта ПОЛУЧАТЕЛЯ, могут только передасты из СберБанка... -- With best regards, Alex Cherednichenko.
Re: Диапазоны PK для филиалов
On Mon, 25 Dec 2006 17:04:55 +0300, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote: > Мда, так хорошо начал... А закончил > банальным полем BaseID в каждой таблице. Минималист я, в основном. Не охота пудрить мозг народу своими (возможно) глупыми идеями. Что-то ценного сказать без глубокого вникания в суть сложно, а вот указать на явные "предположения", которые могут быть ошибочными - нет. Твои размышления по форумам я все скурил. И в моих базах вообще нет BaseID :) Вернее, есть такое поле в некоторых таблицах, но оно совсем о другом. -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
On Mon, 25 Dec 2006 16:49:17 +0300, Alex Cherednichenko <[EMAIL PROTECTED]> wrote: > Но требовать от ОТПРАВИТЕЛЯ знание номера паспорта ПОЛУЧАТЕЛЯ, > могут только передасты из СберБанка... Угу. Мне тут для внесения денег на свой счёт потребовали непременно почтовый индекс своего проживания указать :( Скажите, зачем для конвертации рублей в доллары нужен почтовый индекс? -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
PS. IBP v3 - это мой шатл :-) начни с личной жизни -- Булычев Алексей http://www.stella-npf.ru
Re: Диапазоны PK для филиалов
> > PS. IBP v3 - это мой шатл :-) > > начни с личной жизни К концу года могу, не кривя душой, сказать - у меня с ней "дай бог каждому". Коваленко Дмитрий.
Re: Диапазоны PK для филиалов
WildSery пишет: Tonal, не догнал, чем тебе помогло отдельное поле REPL_ID. Всё равно решение задачи уникальных ID не описано. И что мешает вместо REPL_ID использовать собственно PK ID из этой же таблицы, формируя её по тем же принципам, что и REPL_ID? Я, вобще-то на вопрос топика отвечал: >>был проект с маленьким ТЗ: 1 офис, 1 база, теперь появилась >>необходимость поставить ее в нескольких филиалах. ... С моей точки зрения наиболее быстрый способ и простой поднять репликацию на живой базе. При этом логика все связи, логика базы, данные и написанный код остаётся работоспособным. Метод генерации REPL_ID-а можно выбирать любым удобным, хоть по диапазонам, хоть GUID - по вкусу, главное чтобы в пределах системы не пересекались. Триггера для его вычилления для разных таблиц получаются совершенно идентичными - так что любимый в сообществе китайский метод рулит! ;-) Описанный Коваленко Дмитрием в primary_keys_and_replication метод конечно более гибок, но, по моему, несколько менее прозрачен и тяжелее в реализации. Естественно речь идёт о репликации на уровне записей, а не о репликации на уровне объектов предметной области.
Re: Диапазоны PK для филиалов
On Tue, 26 Dec 2006 11:34:17 +0300, Tonal <[EMAIL PROTECTED]> wrote: > Метод генерации REPL_ID-а можно выбирать любым удобным, хоть по > диапазонам, хоть GUID - по вкусу, главное чтобы в пределах системы не > пересекались. Зависит от схемы репликации. Где все-со-всеми и/или с возможным слиянием данных - уникальные ID свою функцию не выполнят, тот же Дмитрий приводил примеры, показывая, когда они бесполезны. -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
WildSery пишет: Метод генерации REPL_ID-а можно выбирать любым удобным, хоть по диапазонам, хоть GUID - по вкусу, главное чтобы в пределах системы не пересекались. Зависит от схемы репликации. Где все-со-всеми и/или с возможным слиянием данных - уникальные ID свою функцию не выполнят, тот же Дмитрий приводил примеры, показывая, когда они бесполезны. Насчёт все-со-всеми не согласен - если REPL_ID уникальный для всех баз, то схема вполне себе работает. ;-) Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные данные. Подобная ситуация может возникнуть только, если один и тот же объект можно редактировать в разных местах. Универсального решения её не существует, и гибкость решения Дмитрия - всего лишь способ разнести процесс репликации и процесс слияния, который всё равно нужен но у Дмитрия не описан. Но в зависимости от задачи, он может быть очень разный - от примитивной однонаправлинности и приоритетов, до версионности объектов и песочниц.
Re: Диапазоны PK для филиалов
On Tue, 26 Dec 2006 12:57:23 +0300, Tonal <[EMAIL PROTECTED]> wrote: > Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные > данные. Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые данные. -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
> Единственное возражение - слияние данных, когда по одинаковым REPL_ID > разные данные. Подобная ситуация может возникнуть только, если один и > тот же объект можно редактировать в разных местах. > Универсального решения её не существует, и гибкость решения Дмитрия - > всего лишь способ разнести процесс репликации и процесс слияния, который > всё равно нужен но у Дмитрия не описан. > Но в зависимости от задачи, он может быть очень разный - от примитивной > однонаправлинности и приоритетов, до версионности объектов и песочниц. У нас под каждый тип данных - пишется свой алгоритм восстановления в базе данных получателя. Трудоемко с одной стороны и предсказуемо с другой. Коваленко Дмитрий.
Re: Диапазоны PK для филиалов
WildSery пишет: Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные данные. Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые данные. И какие ты видишь проблемы при этом в предложенной мною схеме? Которых нет в других схемах? При обнаружении подобного дубляжа просто грохаем один из объектов, а репликация это разносит по свету. ;-)
Re: Диапазоны PK для филиалов
On Tue, 26 Dec 2006 17:43:37 +0300, Tonal <[EMAIL PROTECTED]> wrote: >>> Единственное возражение - слияние данных, когда по одинаковым REPL_ID >>> разные данные. >> Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые >> данные. > И какие ты видишь проблемы при этом в предложенной мною схеме? > Которых нет в других схемах? > При обнаружении подобного дубляжа просто грохаем один из объектов, а > репликация это разносит по свету. ;-) Разные данные по одному REPL_ID быть не может в принципе - ты утвердил, что REPL_ID уникальны. Надо не просто "грохнуть", надо изменить и все ссылающиеся на "убиваемый" объект записи. А вот если насрать на уникальность, и у каждой базы поддерживать свои ID, то изменятся только данные, из более приоритетного источника. -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
WildSery пишет: On Tue, 26 Dec 2006 17:43:37 +0300, Tonal <[EMAIL PROTECTED]> wrote: Единственное возражение - слияние данных, когда по одинаковым REPL_ID разные данные. Наверное, ты хотел сказать наоборот, когда по разным REPL_ID одинаковые данные. И какие ты видишь проблемы при этом в предложенной мною схеме? Которых нет в других схемах? При обнаружении подобного дубляжа просто грохаем один из объектов, а репликация это разносит по свету. ;-) Разные данные по одному REPL_ID быть не может в принципе - ты утвердил, что REPL_ID уникальны. Но я не утверждал, что данные по одному REPL_ID в разных базах будут идентичны. Простой реальный пример - накладные курьерской доставки. При приходе на склад-получатель состояние накладной изменяется. В то же время, на складе-отправителе выявили ошибку в данных на эту накладную, и исправили её. Если и ошибочные данные, и состояние поля одной таблицы, то возникают разные данные для одного REPL_ID и потребность их сливать. Надо не просто "грохнуть", надо изменить и все ссылающиеся на "убиваемый" объект записи. Естественно. Но и в других системах нужно будет изменять ссылки. В чём проблема то? Или какая-то схема существенно облегчает эту задачу? А вот если насрать на уникальность, и у каждой базы поддерживать свои ID, В "моей" схеме каждая база работает на своих ID. REPL_ID нужен только для механизмов репликации. Это уникальный идентификатор в пределах глобальный системы. то изменятся только данные, из более приоритетного источника. Не совсем понял мысль. А как быть, если нельзя сказать какой источник более приоритетный? В обшем виде задача не решается. Посмотри, например, паралельный ответ Коваленко.
Re: Диапазоны PK для филиалов
> PS. IBP v3 - это мой шатл :-) к слову о шаттлах http://spacenews.ru/spacenews/live/full_news.asp?id=19198 к правильно написанной программе прилагаются правильные условия использования и правильные пользователи в общем нет в мире совершенства (с) Маленький принц -- Булычев Алексей http://www.stella-npf.ru
Re: Диапазоны PK для филиалов
> >> > PS. IBP v3 - это мой шатл :-) > > к слову о шаттлах > > в общем нет в мире совершенства (с) Маленький принц Когда был переход с летнего времени на зимний, я выгреб тонну сообщений об ошибке работы программы, которая запускалась каждые десять минут для создания списка процессов, работающих на сервере. Автор этой программулины был неприятно удивлен существованием ситуации, когда время на вполне законных основаниях прыгает на час назад :) Коваленко Дмитрий.
Re: Диапазоны PK для филиалов
Когда был переход с летнего времени на зимний, я выгреб тонну сообщений об ошибке работы программы, которая запускалась каждые десять минут для создания списка процессов, работающих на сервере. Автор этой программулины был неприятно удивлен существованием ситуации, когда время на вполне законных основаниях прыгает на час назад :) время по гринвичу не прыгает :) -- Булычев Алексей http://www.stella-npf.ru
Re: Диапазоны PK для филиалов
On Wed, 27 Dec 2006 18:11:19 +0300, Boulitchev Aleksey <[EMAIL PROTECTED]> wrote: > время по гринвичу не прыгает :) А как изнутри базы FB получить время по гринвичу? (вопрос не о той программе, конечно же) -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
WildSery wrote: On Wed, 27 Dec 2006 18:11:19 +0300, Boulitchev Aleksey <[EMAIL PROTECTED]> wrote: время по гринвичу не прыгает :) А как изнутри базы FB получить время по гринвичу? (вопрос не о той программе, конечно же) Вызвать удф, которая позвонит в Гринвич и поинтересуеццо... :) -- Regards. Ded.
Re: Диапазоны PK для филиалов
On Wed, 27 Dec 2006 18:43:59 +0300, Ded <[EMAIL PROTECTED]> wrote: > Вызвать удф, которая позвонит в Гринвич и поинтересуеццо... :) Не подходит. В многопользовательской работе слишком много телефонных линий одновременно нужно. -- Сергей Смирнов.
Re: Диапазоны PK для филиалов
"Vladimir A.Bakhvaloff" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > А просто УДФ, которая посмотрит time_zone_information на серваке, и из > текущего времени вычтет соотв. смещение?.. /это я бэз приколов/ > Посмотреть она (УДФ) посмотрит. А вот как определить сколько сегодня к этому времени нужно прибавить, чтобы быть уверенным, что все ползатели уже в кроватках и можно запускать ночные задачи? -- Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: Диапазоны PK для филиалов
WildSery wrote: Угу. Мне тут для внесения денег на свой счёт потребовали непременно почтовый индекс своего проживания указать :( Скажите, зачем для конвертации рублей в доллары нужен почтовый индекс? Они на него делят. Курс теперь такой ;-) для "из рублей в доллары".
Re: Диапазоны PK для филиалов
"Konstantin R. Beliaev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > WildSery wrote: >> Угу. Мне тут для внесения денег на свой счёт потребовали непременно почтовый >> индекс своего проживания указать :( >> Скажите, зачем для конвертации рублей в доллары нужен почтовый индекс? > Они на него делят. Курс теперь такой ;-) для "из рублей в доллары". Ну указал бы случайоно число в диапазоне 00 - 99 :-)
Re: Диапазоны PK для филиалов
On Fri, 29 Dec 2006 10:23:16 +0300, Oleg LOA <[EMAIL PROTECTED]> wrote: >>> Угу. Мне тут для внесения денег на свой счёт потребовали непременно >>> почтовый индекс своего проживания указать :( >>> Скажите, зачем для конвертации рублей в доллары нужен почтовый индекс? >> Они на него делят. Курс теперь такой ;-) для "из рублей в доллары". > > Ну указал бы случайоно число в диапазоне 00 - 99 :-) Не-е-е. Они его ещё сверяют с указанным там же тобой краем или областью проживания. -- Сергей Смирнов.
