|
Что это было?
|
|||
---|---|---|---|
#18+
Что это было? Таблица, расположена на сервере. Поле Deal_ID тип счетчик, ключевое. Значение этого поля как-то изменилось, а в одном из текстовых полей этой записи появились какие-то иероглифы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 18:41 |
|
Что это было?
|
|||
---|---|---|---|
#18+
wladimirrr, какой-то мудрец ручки приложил ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 19:08 |
|
Что это было?
|
|||
---|---|---|---|
#18+
wladimirrr, недавно исправлял подобное - впечатление что проблемы на винте и какой то сектор - небольшой повреждается. там ручки были исключены полностью, причем повреждения были на данных которым лет 8. таблицу поправить не получится, брать из бэкапа. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 20:22 |
|
Что это было?
|
|||
---|---|---|---|
#18+
wladimirrr, Да, такое редко, но бывает, ручки не при чем (они никак ключ-счетчик изменить не могут), винт тоже вряд ли, там или сразу Ж. или начинаются тормоза по базе , а потом Ж.. а вот отключение питания во время записи или сильный провал (типа моргнул свет) это вот самое оно и есть - записалось, но не то и не так... причем страдает не последняя запись, которую пишут, а которые рядом, как будто портится содержимое страницы, ну типа ты на листе А4 ручкой вносишь изменения в конец, а дополнительно портится текст в начале ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 21:32 |
|
Что это было?
|
|||
---|---|---|---|
#18+
vmag wladimirrr, Да, такое редко, но бывает, ручки не при чем (они никак ключ-счетчик изменить не могут), винт тоже вряд ли, там или сразу Ж. или начинаются тормоза по базе , а потом Ж.. а вот отключение питания во время записи или сильный провал (типа моргнул свет) это вот самое оно и есть - записалось, но не то и не так... причем страдает не последняя запись, которую пишут, а которые рядом, как будто портится содержимое страницы, ну типа ты на листе А4 ручкой вносишь изменения в конец, а дополнительно портится текст в начале У клиента базу с таблицами перенесли на новый сервер, и уже 2-й раз за неделю такой финт выскакивает. На старом сервере иногда вообще база ломалась. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 22:05 |
|
Что это было?
|
|||
---|---|---|---|
#18+
Наверное это знак, что бы подумать о хранение данные не в access, а в многопользовательской серверной субд. Морда остается от access, а данные хоть ы том же mssql-server ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2020, 22:34 |
|
Что это было?
|
|||
---|---|---|---|
#18+
wladimirrr На старом сервере иногда вообще база ломалась. я тут с этим делом навозился прилично в свое время, есть статистика, вот именно такая хрень бывает, когда вырубается питание или есть скачки, потом оказывается у одного комп сидел на одной фазе с внешним рекламным банером, у другого с промышленным морозильником на 100 свиней и когда это все постоянно включается/выключается иногда происходят чудеса... существенно сглаживает ситуацию мощный бесперебойник, достаточно чтоб от него питался один системный блок... ну и сюда смотреть тоже нужно bubucha Наверное это знак, что бы подумать о хранение данные не в access по сугубо моим личным выводам mdb практически не убиваем и со всех сторон оптимален если его размер не более 50 мб, база летает даже а самых дохлых компах и даже если ее спроектировал криворуков... если в районе 100 мб, то уже не на всех компах можно работать комфортно, а если планируется больше, нужно слазить с акцесса как хранилища... Ну и все зависит от структуры БД, если там пара таблиц и логики ноль, то можно работать сносно пока не упрешься в 2 гига, а если там есть логика на паутине от 20 таблиц и более и записей в них более 100 т. то на дохлых компах приемлемый потолок БД 50 метров, на хорошем сервере до 200 м ну короче акцесс очень даже не плохая субд и даже как сетевая, но в определенных рамках и с этим нужно считаться ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 00:44 |
|
Что это было?
|
|||
---|---|---|---|
#18+
wladimirrr, Это нарушение целостности данных, за 10 лет в аксессе сталкивался с этим несколько раз. Лечиться при помощи снятия связи между таблицами, и удалением всей цепочки главных проблемных записей(и) и подчинённых записей. Потом связи назад накидываете. Явным признаком также является наличие на уровне подчинённых таблиц строк, которым нет соответствия на уровне главных. Несмотря на наличие связей опять же. Иероглифы реально, не кракозябры а именно иероглифы. Такое появлялось когда кто то случайно сжимал бд при наличии на сервере пользователей. Глаза не видели а руки делали) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 00:52 |
|
Что это было?
|
|||
---|---|---|---|
#18+
vmag по сугубо моим личным выводам mdb практически не убиваем и со всех сторон оптимален если его размер не более 50 мб, база летает даже а самых дохлых компах и даже если ее спроектировал криворуков... если в районе 100 мб, то уже не на всех компах можно работать комфортно, а если планируется больше, нужно слазить с акцесса как хранилища... Ну и все зависит от структуры БД, если там пара таблиц и логики ноль, то можно работать сносно пока не упрешься в 2 гига, а если там есть логика на паутине от 20 таблиц и более и записей в них более 100 т. то на дохлых компах приемлемый потолок БД 50 метров, на хорошем сервере до 200 м ну короче акцесс очень даже не плохая субд и даже как сетевая, но в определенных рамках и с этим нужно считаться Как локальная в одно лицо практически не убиваемая (особенно когда есть бекапы;-) Как сетевая в несколько лиц...из коробки не годится, надо ее готовить. То что она работает у многих - это хорошо, это им повезло, или они смогли приготовить. У меня рабочий объем метров 300 на каждого(локального юзера) и это работает годами, что в общем то понятно. За много лет убилось пару раз и то, во время попыток совместного доступа и еще на кривой сети - кооксиал 10 Мб. НО! база не должна умирать из-за проблем в сети, по сему, ну нах... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 01:02 |
|
Что это было?
|
|||
---|---|---|---|
#18+
насчет 50-100 - не согласен, до гига нормально, однако нужно делать логику такую же как на сервак - т.е. никаких редактирований - только удаления/добавления- (по максимуму), транзакции. на скрине ниже - показаны нарушения - обратите внимание на год 2010(!) - т.е. никаких действий со строками при работе не было, вряд-ли это электричество, хотя 1-е впечатление такое, с другой стороны это mdb... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 08:04 |
|
Что это было?
|
|||
---|---|---|---|
#18+
alecko ..только удаления/добавления... глупости не говорите alecko ..на скрине ниже - показаны нарушения... Целостность mdb файла , как и любого другого, зависит и от состояния носителя, на котором он лежит Вопрос в том, что у mdb, в отличие от серверных субд, нет нормального механизма (журнал транзакций например) для восстановления после сбой ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 11:16 |
|
Что это было?
|
|||
---|---|---|---|
#18+
bubucha, может и глупости - пишу про свой опыт. именно для этих глупостей хорошо подходит отношение 1к1. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 12:05 |
|
Что это было?
|
|||
---|---|---|---|
#18+
alecko именно для этих глупостей хорошо подходит отношение 1к1. извините не догнал, каком раком тут 1к1? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 13:16 |
|
Что это было?
|
|||
---|---|---|---|
#18+
bubucha alecko именно для этих глупостей хорошо подходит отношение 1к1. извините не догнал, каком раком тут 1к1? alecko удаления/добавления- (по максимуму) т.е. есть таблица с основными данными, делаем вторую с изменяемыми. при начальном внесении данных, ключ в основной ID - автоинкремент, в дополнительной ключ- обычный long cкажем IDD. так вот, при удалении из основной старый ключ можно оставить, но сами понимаете нужны усилия, если же работаем с дополнительной, удалили/добавили, редактирование - ключ IDD оставили старый, помощь акса в контроле целостности данных нам в помощь. надеюсь помог выбрать рака. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 14:03 |
|
Что это было?
|
|||
---|---|---|---|
#18+
alecko надеюсь помог выбрать рака. неа, не помог удалении из основной старый ключ можно оставить, но сами понимаете нужны усилия, если же работаем с дополнительной, удалили/добавили, редактирование - ключ IDD оставили старый зачем оставлять старый? каскадное удаление не решает вопрос удаления на уровне движка? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 15:43 |
|
Что это было?
|
|||
---|---|---|---|
#18+
bubucha, к ключу подвязаны и другие таблицы, тогда удалится все, а нам нужно изменить какой-то параметр. для этого этот изменяемый параметр и находится в дополнительной таблице. и его изменение проходит так: чтение в отвязанную форму (это может быть и не отвязанная форма, а скажем, snapshot), редактирование, затем удаление/добавление - один цикл (2 запроса). в случае редактирования запись блокируется, а в данном случае не блокируется (ну, почти). и при этом записи в основной таблице не изменяются и не блокируются. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 16:48 |
|
Что это было?
|
|||
---|---|---|---|
#18+
alecko к ключу подвязаны и другие таблицы, тогда удалится все, а нам нужно изменить какой-то параметр. для этого этот изменяемый параметр и находится в дополнительной таблице. и его изменение проходит так: чтение в отвязанную форму (это может быть и не отвязанная форма, а скажем, snapshot), редактирование, затем удаление/добавление - один цикл (2 запроса). в случае редактирования запись блокируется, а в данном случае не блокируется (ну, почти). и при этом записи в основной таблице не изменяются и не блокируются. Я Вас понял, у Вас свои интимные отношения в плане базостороения, из разряда простое делать сложным... Все эти потуги в виде отвязанных форм и прочего, выхолащивают саму концепцию access как среды - простота... А так то натянуть форму на данные в базе можно менее экзотическими и бесплатными способами ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 17:54 |
|
Что это было?
|
|||
---|---|---|---|
#18+
wladimirrr Что это было? Таблица, расположена на сервере. Поле Deal_ID тип счетчик, ключевое. Значение этого поля как-то изменилось, а в одном из текстовых полей этой записи появились какие-то иероглифы. Отец и сын-дебил стоят на берегу моря. - Вот, сынок, это море. - Где? - Вот это, уходящее в небо, голубое пространство, все это море... - Где? - Видишь, волны играют, чайки снуют туда-сюда, блики от солнца, в дали белый пароходик, запах, непередаваемый запах!... Все это - море! -Где? Отец психует, хватает дебила-сына за загривок и несколько раз макает его башкой в воду: - Вот море! Вот море! Вот море! Вот море! Вот море! Вот море! - папа, папа, что это было?! - Море, сынок... -Где? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 18:31 |
|
Что это было?
|
|||
---|---|---|---|
#18+
bubucha, конечно можно, но вот у меня такой дорогой получилось ходить. нету в аксе простоты, хорошо сделать с кондачка не получится- насмотрелся на эти изыски. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 18:46 |
|
Что это было?
|
|||
---|---|---|---|
#18+
Бубуча прав. Автору топика - забудь про хранение данных в mdb и новых там не помню как. Сколько они мне крови попили лет 20 назад :( Только MS SQL и тому подобные. Акцесс прекрасный инструмент для разработки, но отвратительный для хранения данных. Чем быстрее это поймешь, тем больше нервов сбережешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2020, 22:03 |
|
Что это было?
|
|||
---|---|---|---|
#18+
свои пять копеек. База у клиента в mdb, акс 2003 под 2003 виндовс сервером крутилось на натуральном сервере (пусть и не слишком мощном), с соответствующим железом. Серверные хорошие винты в режиме RAID. То есть даже сбой одного винта не слишком мог повлиять на общее состояние. Достаточно крепкий бесперебойник APC, не шухры мухры. Но раза три случались вышеописанные сбои в ключевых полях со счётчиком (по возрастанию). Например, с десятка тысяч резко нумерация перескакивала на миллионы. Иероглифы в паре полей некоторых подчинённых таблиц - в комплекте. Грешу на выполнение некоторых операций клиентом при подключенных клиентах (кассы), где то периодически не досматривали (программно не контролировалось). ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2020, 14:20 |
|
|
start [/forum/topic.php?fid=45&fpage=13&tid=1609912]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 9ms |
total: | 143ms |
0 / 0 |