Щас просто стоим на распутье, куда идти.. Либо сворачивать либо SQL. Главный аргумент сторонника SQL - это то что все крупные организации работают на SQL.


Так вот. Для статистики, какой размер стабильно работающей базы вы щупали?

опять про пиписьки ...

(10) Если просто перейдете на СКЛ (без прямых запросов) - работать будет тормознее чем на дбф (причем значительно тормознее)

(2) -> (0)

у людей и по 10-15 гиг базы вертятся. тут главное - грамотное построение и закрывающиеся регистры

(2) не обязательно... фарм база крутилась у меня на скуле - каких-либо принципиальных тормозов по сравнению с дбфной В ОПЕРАТИВНОЙ работе - вроде не было. Проблема была только с замедлением группового перевпровдения доков (ибо скуль2000) - но мну это было некритично.
.
скуль - это стабильность.
на дбфе сделать возможноть горячих бэкапов с минимальной периодичностью - я не знаю...

(4) присоединяюсь.
база за 4 гига работала в принципе так же быстро как и в размере полтора гига. объем запрашиваемых итогов - от размера базы не сильно зависит.

(5) >>Проблема была только с замедлением группового перевпровдения доков...
Про это и говорил - для некоторых без перепроведение никуда...

(7) Вот и у нас.  В конце каждого месяца, мы месяц перепроводи раз 5, а в конце квартала весь квартал.

За ночь у меня проводится полтора - два месяца.

(2) В чём сложность перехода на прямые запросы?

(8) при переводе на скуль будет перепроводится за ночь полмесяца... зато есть шанс перевести все на прямые запросы и тогда все будет летать..

(9) нету сложности - нужно 2 вещи - время и деньги.

(9) это другой уровень компетенции
(10) отчеты/обработки на скуль переписать - особо проблем нет, просто вштырить как следует, да и ОТЧЕТЫ - НЕПРИНЦИПИАЛЬНО.
.
а вот если перепиливать алгоритмы проведения - там прсото возможно ПЕРЕПИСАТЬ придется много, просто ТУПО ТЕХНИЧЕСКИ много переписать.
.
но и этого в принципе можно избежать. при перепроведениях - основной тормоз временный расчет на заднее число. Если от него избавиться, то вообщем и без прямых запрсоов мжно жить.

(10) reconnectnative() ?

(12) Вот с задним числом у нас проблемы.... залазить на 1-2 месяца назад и править, у нас обычное дело... И это никак нельзя побороть.. специфика организации такая.

шо еще остались неудачники работающие на клюшках на дбф базах?

(13) это в первую очередь (но на сколько я помню проблема не только в этом)
(15) неудачники на устаревшей 7ке - успешные на высокотехнологичных продуктах от субсистем - это азы и мы их знаем и помним.

(5) есть, урбд называется

(15) иди нафиг с нашей аллейки... окучивай неудачнегов

(14) ПИ..Ж! забороть можно, надо только чтобы это было ДЕЙСТВИТЕЛЬНО НУЖНО.
а так - если исправленяи задним числом идут только в увеличение КОЛИЧЕТСВА на складах - то перепроведение ЗАВЕДОМО будет успешным. и можно даже в фоновом режиме перепроводить в рабочее время... потихоньку.. по 1-2-3 дока...

(17) пока что никто мне внятного ответа не дал: куда пишутся действия в базе (по вводу и првоедению документов) в тот момент когда идет выгрузка в УРБД...

(19) Проводить в рабочее время без переноса ТА?

(20) выгрузка-загрузка УРБД - это вроде как транзакция
т.е. изменения объектов либо до, либо после выгрузки

за перепроведение полтора мес расстреливать - все рещается управленчески

(21) все зависит от ЧАСТНОСТЕЙ, как говорится если хрен дубовый, да дуб хреновый...

(22) и что, у меня складской сборщик будет стоять и ждать...? идите в то место, откуда мы все появились, стакими советами...

(25) да уж....
а что мешает делать обмены каждые 10 минут допустим?
файлы мизерные...занимает всё это 1-3 сек.

+ 26
и у тебя всегда почти актуальная переферийка

(26) данный вопрос ранее уже поставлен в очередь решения, как один из представляющих интерес. Все будет определяться, сколько именно база будет стоять в транзакции при выгрузке.

(27) когда к тебе менегеры придут за деньгами которые онм потерялм изза урбд ты изменишь свое мнение

(29) сбои есть у всех систем
у УРБД их не больше чем у остальных

(290 тема не раскрыта!

(28) всё зависит от объема обмена
если перепровелся документ в пару тысяч строк, то подольше конечно
а для доков в 10-30 строк - это всё быстро происходит

(32) у меня доки по 300-400 строк - в порядке вещей. но что плюс - все работают только в ТА, и за 10 минут 4 манагера суммарно могут доков навводить тысч на 5 строк...

(31) была у меня неприятная история когда закуп в юсд шел урбд стояла, менегеры удаленно сидели и в заказах партии подбирали так как от маржи их зп зависила ...дальще рассказывать ?

(34) мы говорим сейчас о бекапе
т.е. переферийная база-приемник только получает данные
в ней никаких изменений не ведётся

(33) секунд 10-15 на выгрузку
зависит от компа

(23) Ну иногда это бывает из-за непреодолимых обстоятельств. Например самое распростронённое у нас - это поступление импорта. Допустим идёт 4 контейнера, партия одна. После таможни один контейнер уже разгрузился у нас и всё продали с него, второй контейнер только разгружается, третий контейнер в пути от таможни, а четвёртый контейнер ещё на таможне может или 1 день простоять или 1 месяц. А себестоимость всей партии точно можно узнать только когда растаможится последний контейнер.  Так вот все доп расходы ложаться в эту партию и заносятся только когда будет разгружен последний контейнер, а порой проходит больше месяца. Вот задним числом эти данные и вбивают.

(36) понял, все на серваке - должно по идее быстро быть...

+36
у меня выгрузка за день (это около 3000 доков с движениями по 2-3 регистрам) проходит секунд за 20-30

+39
среднее количество строк в документе - 25-30

> вот все доп расходы ложаться в эту партию
- где-то у вс что-то в консерватории неправильно...
.
если право собственности переходит к вам после растаможки - то это все отдельные партии и нехрен ждать чего-то и правит задним числом - вводим/приходуем по факут
.
если право собственности переходит к вам по факту отгрузки за рубежом - то доп расходы - по каждой ГТД шке кладутся отдельно, затраты на перевозку - или целиком на партию или на конкретную часть партии если контейнеры довозятся...
.
ну фиг с ним.
.проще сделать чтобы допрасходы падали текущим временем - хоть на всю hgfhnb.? хот ь на ее часть.. да.. но тут вылазит бухия.. которая это все может поломать...
.
короче - смотреть надо.. м.б. удастся извернуться  допрасходы уронить текущим числом...

(39) сервер/комп?

(42) на сервере

(43) понял, с текучкой разгребусь - попробую.
.
в УРБД я ноль практически - поможешь по елочи?

(42) причем, как я уже писал, если в периферийке данных никаких не менять, то обратная выгрузка - секунда-две
там только подтверждение о загруженных данных

(41)см 23

(46) нуну.. япосмотрю как ты откажешься от исправленяи документа задним числом месячной давнойти когда из сетевого магазин откуданить из волгограда или другого мухосранска приедт дебет =-нота с требованием предоставить исправленные документы (не корректировочные). и все. и апож. с сетками особо не пободаешься. хоть обуправляйся. но - боремся! ;-)

(44) без проблем
для автоматизации этого процесса есть замечательная и недорогая программка УРБД-мастер
ищется в любом поисковике

плюс всей этой системы в том, что в случае вылета основной базы всё легко разворачивается из почти актуальной периферийной базы за каких-то полчаса

(48) угумс, спсб!

ладно, всем спсб! пошел упаду в ванну книжку дочитаю страниц 200

(49) мыло в профиле есть
если что-пиши, спрашивай

(47) да норм все ) приходят такие тр)

3 Гб, больше не довелось, ибо работаю только с восьмёркой

(0) 7 Гб вся база
Самый большой файл - 1,3 Гб
Используется kernel33

(19) Случай из практики. Принесли служебку, мол накосячили в приходе, не те цены поставили, нужно исправить. Ок, исправляем. Через полчаса после исправления. Новая служебка ... вообщем цены там были правильные и не нужно исправлять.... верните все обратно. Так что идеотизм отдельных личностей не знает границ

(37) Исходя из того что ГБ всегда прав могу только посоветовать вашему ГБ посмотреть в сторону банковского учета. Там нет такого понятия как вчерашний день, не говоря о месяце как у вас. Там все сидят до упору пока незакроют текущий день. У вас же ГБ явно булки расслабил, при попустительстве директора, которому либо глубоко на все ***, либо жаба душит денег заплатить другим ГБ за консультацию. В общем нормально себестоимость выводится уже после продажи товара, неважно частичной или полной. И даже корректируется текущим периодом прошлые периоды. И ничего военного тут нету.
Так что про специфику ненужно тут ля-ля. Знаем, плавали.
На скуль переводят базы в первую очередь что б не заниматься ритуалом обрезания, а иметь возможность в одной базе посмотреть прошлые периоды и сравнить динамику и пр. Плюс, как уже говорилось, возможность бекапов, реиндексаций, ... средсвами скуля.
Насчет замедления работы. Да, отчеты которые в дбф выплевывали данные, тут будут вызывать недоумение а иногда и панику. При переписи на прямые запросы когда возьмете большой период, то скуль выплюнет результат быстрее. Ну и т.д.
При все плюсах и минусах переход на скуль все же более плюсовой. Единственное неэкономить на железе и изначально его правильно настроить. И неберите большие диски, 8х150 GB для работы и терабайтник для файлопомойки вполне хватит.

Вопрос такой -а насколько важно,чтобы главбух работал в оперативной базе -не проще ли сделать копиюи ему персонально выгружать всё,что нужно из рабочей,а в рабочей просто расстаться с бух-итогами,так как они съедают место и время.

(0) По хорошему там надо все ЕДРО переписывать, чтобы не было ограничений на 2 гига и известных ошибок (фирма-разработчик ядра кстати так и сделала). Hogik прикрутил другие движки и исправил ряд известных ошибок патчами. Я не очень представляю зачем файл-серверные движки нужны были вообще, разве что как наследие MS-DOS.