Автор | Сообщение |
|
| постоянный участник
|
Пост N: 1506
Зарегистрирован: 12.09.06
|
|
Отправлено: 06.08.10 12:20. Заголовок: Как запретить работу с чужими базами ?
Всем привет ! Кто может подсказать по следующему вопросу: Имеется своя программа, базы данных: dbf-файлы, индексы: cdx. Этой программой пользуются определенное кол-во фирм. Программа привязана на ключ (HASP HL). Как можно запретить "открывать" чужие базы (моя программа) из других фирм ? Т.е. допустим на одной фирме кто-то забрал базы (моя программа), передал другой фирме, а там можно открыть эти базы в моей программе и спокойно работать с ними.
|
|
|
Ответов - 45
, стр:
1
2
3
All
[только новые]
|
|
|
| |
Пост N: 1846
Зарегистрирован: 17.05.05
|
|
Отправлено: 06.08.10 12:30. Заголовок: Где то была такая те..
Где то была такая тема :)
|
|
|
|
| постоянный участник
|
Пост N: 1507
Зарегистрирован: 12.09.06
|
|
Отправлено: 06.08.10 12:37. Заголовок: Dima пишет: Где то ..
Dima пишет: цитата: | Где то была такая тема :) |
| Прошло время, может кто-то по новому сможет предложить решение данной проблемы.
|
|
|
|
| |
Пост N: 1847
Зарегистрирован: 17.05.05
|
|
Отправлено: 06.08.10 12:41. Заголовок: Да вроде просто ФСЁ ..
Да вроде просто ФСЁ ;) Только нужно продумать как все это верно замутить. На компе в файле (или в реестре) , храним предположим MD5 (тут могут варианты) всех реквизитов организации (или части реквизитов). Пришел чел с левой базой и пытается зайти в прогу и тут........понял ? :) Еще вариант ;) Привязка проги к MAC адресу сетевой карты.
|
|
|
|
| постоянный участник
|
Пост N: 1509
Зарегистрирован: 12.09.06
|
|
Отправлено: 06.08.10 13:12. Заголовок: Не совсем просто. У..
Не совсем просто. У меня есть номер ключа HASP HL. Я по нему могу определять, чья задача и не надо мне MAC адресу сетевой карты или MD5 всех реквизитов организации .... Как сделать привязку DBF-ника баз на конкретную организацию ? Dima пишет: цитата: | Пришел чел с левой базой и пытается зайти в прогу и тут.... |
| Этот чел переписал 3-4 больших баз и справочники и все .... вуаля.... РАБОТАЕТ с чужой базой...
|
|
|
|
| |
Пост N: 87
Зарегистрирован: 04.12.07
|
|
Отправлено: 06.08.10 14:18. Заголовок: Первое, что приходит..
Первое, что приходит на ум, чтобы гарантированно запретить - это шифрование баз (хотя бы основных) по тому же номеру ключа, например.
|
|
|
|
| |
Пост N: 1848
Зарегистрирован: 17.05.05
|
|
Отправлено: 06.08.10 14:29. Заголовок: КСС пишет: Первое, ..
КСС пишет: цитата: | Первое, что приходит на ум, чтобы гарантированно запретить - это шифрование баз (хотя бы основных) по тому же номеру ключа |
| Кстати да , вариант !
|
|
|
|
| постоянный участник
|
Пост N: 1511
Зарегистрирован: 12.09.06
|
|
Отправлено: 06.08.10 14:59. Заголовок: КСС пишет: это шифр..
КСС пишет: цитата: | это шифрование баз (хотя бы основных) по тому же номеру ключа, |
| Это интересно. Для локального варианта это ХОРОШИЙ выход. Как реализовать ? Примерчик небольшой можно ? (Заранее спасибо !) Но вот для сетевой версии программы, когда ключей несколько, то это наверно облом ! Хотя можно придумать БАЗУ шифра, в которой будут храниться номера ключей, а КОД-шифрования будет общим. А как тогда обеспечить подключение "правильных" своих пользователей и не давать подключаться "левым" пользователям ? И еще тогда меня интересует как будет вести себя ОБЩАЯ база (шифрованная) в многопользовательском режиме ? У кого есть опыт ?
|
|
|
|
| |
Пост N: 1849
Зарегистрирован: 17.05.05
|
|
Отправлено: 06.08.10 15:22. Заголовок: Andrey пишет: И еще..
Andrey пишет: цитата: | И еще тогда меня интересует как будет вести себя ОБЩАЯ база (шифрованная) в многопользовательском режиме ? |
| У меня есть печальный опыт на Clipper + SIX. Упала как то шифрованная база , не было на компе бесперебойника. Половина базы осталась вообще не понятно в каком виде , расшифровать так и не удалось. С тех пор не шифрую шибко большие базы , только "особо секретные" ;) Возможно X(Harbour) ведет себя корректнее в таких случаях , не проверял.
|
|
|
|
| постоянный участник
|
Пост N: 49
Зарегистрирован: 29.05.06
|
|
Отправлено: 06.08.10 17:40. Заголовок: Возможно, устроит та..
Возможно, устроит такое решение. На мой взгляд, достаточно дёшево, сердито и с минимальными доработками :) 1. Каждая DBF – таблица ( ну или не каждая, а по выбранная возможному интересу для недоброжелателей или другому критерию ) дополняется полем для записи некоторого кода ( назовём его это поле CRYPTFIELD ) 2. Значение для записи в CRYPTFIELD вычисляется на основе содержимого всех ( ну или опять-же не всех, а на усмотрение разработчика ) полей записи и некоторого ключа шифрования, который уникален для конкретного пользователя ( можно вписывать в экземпляр программы или получать из HASP ) 3. При обновлении полей отдельной записи соответственно обновляется и содержание CRYPTFIELD. 4. При запуске программы проверяется совпадение содержимого CRYPTFIELD и используемых для его генерации полей записях так в сотне, отобранных случайным порядком по всей DBF-таблице. 5. Если случаев несовпадений слишком много ( процентов так 10, например ) - значит, DBF-таблицы скорее всего записывались с отличным от используемого ключа шифрования, то есть имеет место попытка доступа к чужим данным, запретом чего мы и озадачены. Разрушения файла по обычным причинам ( висяки, отключения питания и тд ) в таком случае распространяться будут опять-же только на те записи файла, которые не успеют переписаться из буфера на диск.И - CRYPTFIELD в случае разрушений может оказаться подспорьем для обнаружения разрушенных записей.
|
|
|
|
| постоянный участник
|
Пост N: 1513
Зарегистрирован: 12.09.06
|
|
Отправлено: 06.08.10 18:26. Заголовок: G-Serge пишет: Возм..
G-Serge пишет: цитата: | Возможно, устроит такое решение. |
| Устроит. Еще как устроит !!! Что-то подобное думалось мне, но решил спросить профессионалов. G-Serge пишет: цитата: | . Значение для записи в CRYPTFIELD вычисляется на основе содержимого всех ( ну или опять-же не всех, а на усмотрение разработчика ) полей записи и некоторого ключа шифрования, который уникален для конкретного пользователя ( можно вписывать в экземпляр программы или получать из HASP ) |
| Можете разъяснить поподробней ?
|
|
|
|
| постоянный участник
|
Пост N: 50
Зарегистрирован: 29.05.06
|
|
Отправлено: 06.08.10 18:34. Заголовок: Например, просуммиру..
Можно и поподробней :) Всё-таки центральный момент :) Например, просуммировать все числовые поля, умножить на сумму всех asc() символов строковых полей, а итог разделить на номер кода ключа. Целую часть полученного результата ( или несколько последних цифр , зависит от длины CRYPTFIELD ) записать в CRYPTFIELD. Главное - соответствие содержимого CRYPTFIELD всей этой арифметике в КАЖДОЙ записи базы данных :)
|
|
|
|
|
| постоянный участник
|
Пост N: 51
Зарегистрирован: 29.05.06
|
|
Отправлено: 06.08.10 19:22. Заголовок: И вдогонку :) Отдель..
И вдогонку :) Отдельное поле для проверочного значения можно и не вводить. Вместо этого можно заполнить ПЕРВЫЕ несколько записей базы данных значениями, которые опять-же будут соответствовать некоторому ключу. Хотя подбирать значения для полей исходя из ключа - задача ещё более творческая :)
|
|
|
|
| постоянный участник
|
Пост N: 1514
Зарегистрирован: 12.09.06
|
|
Отправлено: 06.08.10 20:17. Заголовок: G-Serge пишет: прос..
G-Serge пишет: цитата: | просуммировать все числовые поля, умножить на сумму всех asc() символов строковых полей, а итог разделить на номер кода ключа. |
| Это круто ! При изменение структуры базы, придется еще и пересчитывать все записи ! А нет ли какой готовой функции в Харборе подсчета (типа MD5) полей БД ? G-Serge пишет: цитата: | Вместо этого можно заполнить ПЕРВЫЕ несколько записей базы данных значениями, которые опять-же будут соответствовать некоторому ключу. |
| Тогда их нужно делать удаленными, чтоб в подсчетах не участвовали и не выводились вообще ! А этот метод можно будет легко подделать....
|
|
|
|
| постоянный участник
|
Пост N: 52
Зарегистрирован: 29.05.06
|
|
Отправлено: 06.08.10 20:46. Заголовок: Andrey пишет: Это к..
Andrey пишет: цитата: | Это круто ! При изменение структуры базы, придется еще и пересчитывать все записи ! |
| Это не круто - это для примера :) Ограничьтесь парочкой полей и придумайте свой алгоритм. Ну, и поля подбирайте такие, чтобы в дальнейшем изменение структуры их не затронуло. Andrey пишет: цитата: | Тогда их нужно делать удаленными, чтоб в подсчетах не участвовали и не выводились вообще ! А этот метод можно будет легко подделать.... |
| Здесь тоже возможны варианты :) Всё зависит от того, КАК конкретная база данных используется. Главное - с одной стороны не поддаваться паранойе, что кому-то кровь из носу требуется вашу защиту данных обойти, а с другой стороны - не делать защиту излишне очевидной. Продемонстрировать клиенту, что ЕГО, КЛИЕНТА данные не читаются на машине с ЧУЖИМ ключом - это одно, всерьёз предполагать, что ОДИН ИЗ ВАШИХ КЛИЕНТОВ позаимствует файлы данных у ДРУГОГО ВАШЕГО КЛИЕНТА - это другое. Если речь идёт о защите персональных данных - не знаю, что посоветовать. Люди, которые назначены кормиться от этой темы, примут только те решения, которые сертифицированы, а под прочими , в том числе под изысками программистов-индивидуалистов, подпись свою не поставят. Поскольку это предполагает хоть какую-нибудь, но ответственность, а они в массе своей кроме как на бла-бла-бла и высасывание из пальцев рекомендаций неспособны, а жрать им хочется.
|
|
|
|
| |
Пост N: 88
Зарегистрирован: 04.12.07
|
|
Отправлено: 07.08.10 05:55. Заголовок: Если рассматривать с..
Если рассматривать самый простой вариант, то я бы сделал примерно следующее: 1) единственное, что отличает базы данных клиентов - это аппаратные ключи (компьютеры и их внутренности исключаем); 2) у меня в базе данных всегда есть таблица через которую пользователи авторизуются, хранят и получают настройки программы и прочее. В этой таблице у меня лично, только одно поле с неопределённым названием типа Fld1 и она зашифрована; 3) при первичной установке программы запускаем нашу программу с определённым параметром. Этот параметр запускает функцию, которая записывает номер HASP ключа в одно из полей (или как у меня - в определённое место поля) каждого пользователя; 4) теперь во время авторизации сверяем текущий ключ с разрешённым пользователю. Такой вариант позволит даже разделить доступ пользователям к разным БД по разным ключам, если таковых установлено несколько.
|
|
|
|
| постоянный участник
|
Пост N: 1515
Зарегистрирован: 12.09.06
|
|
Отправлено: 07.08.10 13:36. Заголовок: КСС Спасибо БОЛЬШО..
КСС Спасибо БОЛЬШОЕ за идею ! Я такой вариант вообще не рассматривал.... Даже изящное решение.... А с какими ключами HASP работаешь ?
|
|
|
|
| |
Пост N: 9
Зарегистрирован: 17.06.10
|
|
Отправлено: 08.08.10 13:03. Заголовок: А может эту инфу в з..
А может эту инфу в заголовок DBF класть. Там, помнится, 31/32 байты резервированы
|
|
|
|
| постоянный участник
|
Пост N: 1520
Зарегистрирован: 12.09.06
|
|
Отправлено: 08.08.10 19:57. Заголовок: fil пишет: А может ..
fil пишет: цитата: | А может эту инфу в заголовок DBF класть. Там, помнится, 31/32 байты резервированы |
| Т.е. туда можно записать свои 2 байта ? А как бы точно узнать ?
|
|
|
|
| |
Пост N: 10
Зарегистрирован: 17.06.10
|
|
Отправлено: 08.08.10 20:43. Заголовок: Не понял, чего узнат..
Не понял, чего узнать ? Гуглим формат DBF. При инсталяции проги fwrite в DBF-ы признака пользователя(группы пользователей)
|
|
|
|
| постоянный участник
|
Пост N: 1530
Зарегистрирован: 12.09.06
|
|
Отправлено: 17.08.10 12:10. Заголовок: fil пишет: А может ..
fil пишет: цитата: | А может эту инфу в заголовок DBF класть. Там, помнится, 31/32 байты резервированы |
| Не прокатит ! А если придет кому нибудь в голову, добавить в рабочую базу через утилиты (DBU или другие) записи другой "стыренной" базы ? Слишком легкая защита !
|
|
|
|
| |
Пост N: 18
Зарегистрирован: 17.06.10
|
|
Отправлено: 17.08.10 12:52. Заголовок: Чего, не прокатит ? ..
Чего, не прокатит ? Задача была - осложнить жизнь челу сперевшему базу. В DBF все/некоторые поля криптированы. В 2 байтах держим уникальное имя запихиваемое туда при инсталяции проги. Есть ключевой файл/ветка реестра с эти именем в коем прописаны всякие атрибуты пользователя и число строк DBF и т.п.
|
|
|
|
|
| постоянный участник
|
Пост N: 53
Зарегистрирован: 29.05.06
|
|
Отправлено: 17.08.10 12:54. Заголовок: Andrey пишет: fil п..
Andrey пишет: цитата: | fil пишет: цитата: А может эту инфу в заголовок DBF класть. Там, помнится, 31/32 байты резервированы Не прокатит ! А если придет кому нибудь в голову, добавить в рабочую базу через утилиты (DBU или другие) записи другой "стыренной" базы ? Слишком легкая защита ! |
| Можно сделать инфу в заголовке DBF зависимой не только от значения ключа, но и от числа записей в базе данных. Хотя маловато будет 2 байта, думаю. А вообще, неплохой подход. Я так думаю, про ключ в заголовке файла "взломщики" очень не скоро додумаются... Особенно если в порядке дымовой завесы сделать в рабочем каталоге парочку-троечку файлов с названием ( или полями ) типа SECRET_KEY , HASP_KEY и тд :) Нехай экспериментируют... :)
|
|
|
|
| |
Пост N: 19
Зарегистрирован: 17.06.10
|
|
Отправлено: 17.08.10 13:04. Заголовок: В общем, совершенно ..
В общем, совершенно неважно чего пихать в заголовок. По сути это флаг инсталяции. Хотя, конечно, можно затолкать в эти 2 байта число до 65 тыс.
|
|
|
|
| постоянный участник
|
Пост N: 54
Зарегистрирован: 29.05.06
|
|
Отправлено: 17.08.10 13:18. Заголовок: fil пишет: В общем,..
fil пишет: цитата: | В общем, совершенно неважно чего пихать в заголовок. По сути это флаг инсталяции. Хотя, конечно, можно затолкать в эти 2 байта число до 65 тыс. |
| В принципе, да. Из всех имеющихся для проверки соответствия параметров ( код ключа, количество записей в базе и тд ) можно сгенерить достаточно уникальное ( с вероятностью повтора 1/65000 ) число.
|
|
|
|
| постоянный участник
|
Пост N: 1531
Зарегистрирован: 12.09.06
|
|
Отправлено: 19.08.10 08:27. Заголовок: А как интересно это ..
А как интересно это решается в других системах, типа 1С или других ?
|
|
|
|
| |
Пост N: 1
Зарегистрирован: 19.08.10
|
|
Отправлено: 19.08.10 09:10. Заголовок: в других системах, т..
в других системах, типа 1С - никак. Когда-то применял следующее: на числовые значения - NtoC() в 36-ричную систему, а на важные текстовые - XOR() с введенным паролем (или считанным ключом) при шифровании (и с ним же при дешифровании). Данные вроде есть, но воспользоваться без верного ключа затруднительно. Еще вариант: таблицы и индексы _хранить_ в зашифрованных архивных файлах, а при старте задачи распаковывать. Соответственно, при закрытии - запаковывать заново. И не забыть под конец удалить распакованные :-)
|
|
|
|
| постоянный участник
|
Пост N: 1546
Зарегистрирован: 12.09.06
|
|
Отправлено: 08.09.10 14:34. Заголовок: Chikanuk пишет: таб..
Chikanuk пишет: цитата: | таблицы и индексы _хранить_ в зашифрованных архивных файлах, а при старте задачи распаковывать. Соответственно, при закрытии - запаковывать заново. И не забыть под конец удалить распакованные |
| Слишком медленно все будет ! Базы за 1 Gb у некоторых переваливает ....
|
|
|
|
| постоянный участник
|
Пост N: 1547
Зарегистрирован: 12.09.06
|
|
Отправлено: 08.09.10 14:40. Заголовок: КСС А с какими ключ..
КСС А с какими ключами HASP работаешь ?
|
|
|
|
| постоянный участник
|
Пост N: 1549
Зарегистрирован: 12.09.06
|
|
Отправлено: 10.09.10 20:34. Заголовок: Вопрос такой: можно ..
Вопрос такой: можно ли зашифровать текстовые данные в DBF файле и перед показом в Tbrowse расшифровывать ? Тогда если база случайно грохнется, то можно будет восстановить данные, с потерей некоторого количества записей.... Это терпимо. Процесс шифрования и расшифрования понятен. В ключе HASP HL есть криптопроцессор. В крайнем случае можно воспользоваться и Харборовскими функциями шифрации. А как показывать записи в стандартном Tbrowse ? Тогда вопрос об "обмене" баз между фирмами пропадет вообще. Да и приглашенные со стороны спецы "пролетают" ...
|
|
|
|
| постоянный участник
|
Пост N: 455
Зарегистрирован: 27.01.07
|
|
Отправлено: 11.09.10 11:43. Заголовок: Andrey пишет: А как..
Andrey пишет: цитата: | А как показывать записи в стандартном Tbrowse ? |
| Создать свой блок кода для шифрованного поля. Или я не понял вопрос?
|
|
|
|
| постоянный участник
|
Пост N: 1552
Зарегистрирован: 12.09.06
|
|
Отправлено: 11.09.10 15:08. Заголовок: PSP пишет: Создать ..
PSP пишет: цитата: | Создать свой блок кода для шифрованного поля. |
| Т.е. для всех текстовых полей создать свой блок кода ? А как он будет примерно выглядеть ?
|
|
|
|
|
| постоянный участник
|
Пост N: 457
Зарегистрирован: 27.01.07
|
|
Отправлено: 11.09.10 19:04. Заголовок: Покажи свой код TBro..
Покажи свой код с TBrowse.
|
|
|
|
| |
Пост N: 321
Зарегистрирован: 03.12.08
|
|
Отправлено: 23.08.16 15:42. Заголовок: Оживляю тему . Есть..
Оживляю тему . Есть-ли способ работы с шифрованной DBF ? Вроде как-то видел даже примеры где "на лету" осуществляется кодирование/декодирование и запись/чтение . Не могу вспомнить как это работает .....
|
|
|
|
| |
Пост N: 5982
Зарегистрирован: 17.05.05
|
|
Отправлено: 23.08.16 16:03. Заголовок: Softlog86 Можно поп..
Softlog86 Можно попробовать SX_* функции или почитать это Я как то баловался с шифрованием в Clipper+SIX. В случае падения проги , падения компа , в общем не нормальном завершении программы , в базе может быть каша , часть записей зашифрована , часть нет. После пары экспериментов , плюнул на это дело
|
|
|
|
| постоянный участник
|
Пост N: 1164
Зарегистрирован: 17.02.12
|
|
Отправлено: 23.08.16 16:11. Заголовок: Softlog86 Было в SI..
Softlog86 Было в SIXNSX USE: Syntax: USE <(db)> ; [VIA <rdd>] ; [ALIAS <a>] ; [<new: NEW>] ; [<ex: EXCLUSIVE>] ; [<sh: SHARED>] ; [<ro: READONLY>] ; [INDEX <(index1)> [, <(indexn)>]] ; [TRIGGER <trig>] ; [PASSWORD <password>] Generally, this command works the same way as it does in Clipper. The only difference being the TRIGGER and PASSWORD clauses. TRIGGER - Allows you to assign a custom trigger function to this table's workarea. PASSWORD - Set an encryption password to be used in opening this table. смотрим hbsix.ch /* * USE command with support for TRIGGER and PASSWORD clauses */ #command USE <(db)> [VIA <rdd>] [ALIAS <a>] [<nw: NEW>] ; [<ex: EXCLUSIVE>] [<sh: SHARED>] [<ro: READONLY>] ; [CODEPAGE <cp>] [INDEX <(index1)> [, <(indexN)>]] ; [TRIGGER <trig>] [PASSWORD <pass>] => ; [sx_SetTrigger( TRIGGER_PENDING, <trig>, <rdd> );] <-trig-> ; [sx_SetPass( <pass>, 1, <rdd> );] <-pass-> ; dbUseArea( <.nw.>, <rdd>, <(db)>, <(a)>, ; iif( <.sh.> .OR. <.ex.>, ! <.ex.>, NIL ), <.ro.> [, <cp>] ) ; [; dbSetIndex( <(index1)> )] ; [; dbSetIndex( <(indexN)> )] вроде как должно быть шифрование
|
|
|
|
| постоянный участник
|
Пост N: 1165
Зарегистрирован: 17.02.12
|
|
Отправлено: 23.08.16 16:20. Заголовок: Dima пишет После пар..
Dima пишет цитата: | После пары экспериментов , плюнул на это дело |
| У меня работало нормально и не ломалось практически, но тоже ушел с шифрования, т.к. надо иметь сервисныей проги для "навсякий случай" - через время они попадали к др.людям (обслуживающим базу) самому не разорваться во все места и в целом (во времени) потеряло смысл.
|
|
|
|
| |
Пост N: 5983
Зарегистрирован: 17.05.05
|
|
Отправлено: 23.08.16 16:29. Заголовок: SergKis пишет: У ме..
SergKis пишет: цитата: | У меня работало нормально и не ломалось практически |
| Ты наверное жестко не тестил. Я к примеру убивал задачу во время ее работы с базой , тупо нажимал Reset на ящике и после смотрел как поживает база. То что увидел , не понравилось и забил :)
|
|
|
|
| постоянный участник
|
Пост N: 1166
Зарегистрирован: 17.02.12
|
|
Отправлено: 23.08.16 16:38. Заголовок: Dima пишет Ты наверн..
Dima пишет цитата: | Ты наверное жестко не тестил. |
| Молотком точно не бил Работала у клиентов в реальном времени несколько лет, потом убрал шифрование и работает до сих пор
|
|
|
|
| |
Пост N: 5984
Зарегистрирован: 17.05.05
|
|
Отправлено: 23.08.16 16:41. Заголовок: SergKis пишет: Моло..
SergKis пишет:
|
|
|
|
| постоянный участник
|
Пост N: 5057
Зарегистрирован: 12.09.06
|
|
Отправлено: 23.08.16 18:05. Заголовок: Dima пишет: Ты наве..
Dima пишет: цитата: | Ты наверное жестко не тестил. Я к примеру убивал задачу во время ее работы с базой , тупо нажимал Reset на ящике и после смотрел как поживает база. То что увидел , не понравилось и забил :) |
| Интересно, а как будет поживать после этого MySql или PostgeSql ?
|
|
|
|
| |
Пост N: 5985
Зарегистрирован: 17.05.05
|
|
Отправлено: 23.08.16 19:15. Заголовок: Andrey пишет: Интер..
Andrey пишет: цитата: | Интересно, а как будет поживать после этого MySql или PostgeSql ? |
| Проверь :)
|
|
|
|
|
| |
Пост N: 1045
Зарегистрирован: 20.02.11
|
|
Отправлено: 23.08.16 20:33. Заголовок: Andrey пишет: Интер..
Andrey пишет: цитата: | Интересно, а как будет поживать после этого MySql или PostgeSql ? |
| ничего не будет если эту кнопку жать не на серваке где этот скуль установлен . клиент работает не с самой таблицей ,а с курсором этой таблицы. Если на клиенте ткнуть в резет, то фатальных последствий для базы на сервере не будет. .... но, присоединяюсь к совету Димы
|
|
|
|
| постоянный участник
|
Пост N: 1167
Зарегистрирован: 17.02.12
|
|
Отправлено: 23.08.16 20:57. Заголовок: Haz пишет ничего не ..
Haz пишет цитата: | ничего не будет если эту кнопку жать не на серваке где этот скуль установлен |
| Сервака без УПС как то и не видел уже цитата: | .... но, присоединяюсь к совету Димы |
| Только обязательно кувалдометром проверять
|
|
|
|
| постоянный участник
|
Пост N: 1258
Зарегистрирован: 27.01.07
|
|
Отправлено: 23.08.16 20:59. Заголовок: Если б SQL-сервер бы..
Если б SQL-сервер был устойчивым к внезапному прерыванию и гарантировал целостность данных в такой ситуации, никто бы не изобретал UPS-ы, RAID-ы, избыточность и архивные копии)))
|
|
|
|
| |
Пост N: 5986
Зарегистрирован: 17.05.05
|
|
Отправлено: 23.08.16 21:27. Заголовок: Haz пишет: ничего н..
Haz пишет: цитата: | ничего не будет если эту кнопку жать не на серваке где этот скуль установлен . |
| Упс , не успел ....опередили меня (ходил погулять) В целом так и и есть. Жестко тестил задачу под ADS , долго мучал раб. станцию , в итоге с базой на серваке все норм.
|
|
|
Ответов - 45
, стр:
1
2
3
All
[только новые]
|
|