Померяемся?

Ваші пропозиції щодо розширення функціоналу програми.
GreN
Повідомлень: 8
З нами з: 29 червня 2015, 13:21

Re: Померяемся?

Повідомлення GreN » 30 червня 2015, 11:28

priup писав:
abaddon89 писав:а ведь человек не слабо так ковырнул в суть проблемы. Всё описал. Поделился на форуме. Прям выполнил чью-то работу. А его за это.......
А не верю я, что это клиент!
База 210 гБ, А ЗАРЕГИСТРИРОВАЛСЯ НА ФОРУМЕ - вчера!!!! :o
Да само содержание топика проявляет конкурента!!!!! :mrgreen:
На сервер приложений поставлю visual studio и в режиме дебага подключусь к процессу сервера приложений, ждите новых занимательных сообщений :)

GreN
Повідомлень: 8
З нами з: 29 червня 2015, 13:21

Re: Померяемся?

Повідомлення GreN » 30 червня 2015, 11:39

priup писав:Не , ну чё за страна, блин............
У них:
GreN писав:..... Размер базы 210 гб. сетевая версия. ................
А им всё равно жалко денег на СУДБ Oracle:
GreN писав:....... разработчики допилсят сервер приложений то и на Firebird будет все ок
За какие шиши програмёры разработчика будут "ДОПИЛИВАТЬ"?
За зарплату в 4-6 тыс ГРН????? :shock:
Обратитесь непосредственно к разрабам по телефону(на сайте) , они проведут анализ и выставят Вам счёт на "ДОПИЛИВАНИЕ".
После оплаты они ВАМ допилят....................... 8-)

За зарплату в 4-6 тыс ГРН????? :shock: - уровень свойей заработной платы разработчик может обсудить с куководителем, но пока качество продукта заставляет желать лучшего....

GreN
Повідомлень: 8
З нами з: 29 червня 2015, 13:21

Re: Померяемся?

Повідомлення GreN » 30 червня 2015, 11:41

GreN писав:
priup писав:
abaddon89 писав:а ведь человек не слабо так ковырнул в суть проблемы. Всё описал. Поделился на форуме. Прям выполнил чью-то работу. А его за это.......
А не верю я, что это клиент!
База 210 гБ, А ЗАРЕГИСТРИРОВАЛСЯ НА ФОРУМЕ - вчера!!!! :o
Да само содержание топика проявляет конкурента!!!!! :mrgreen:

На сервер приложений поставлю visual studio и в режиме дебага подключусь к процессу сервера приложений, ждите новых занимательных сообщений :)

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Померяемся?

Повідомлення Ktoia » 30 червня 2015, 12:40

GreN, респект. priup, а какая разница верите Вы или нет в то что это клиент, это как то меняет дело работоспособности медка с ФБ? Есть проблема работы медка с большой базой ФР? Есть!!! Проблема устраняется разработчиками медка? Нет! Вместо того что бы сказать спасибо GreN-у за столь глубокий анализ проблемы, Вы его....Да и какой смысл конкуренту анализировать медок, и тем более предлагать пути решения проблемы??? ну да ладно это риторика. У меня вот тоже БД на ФБ была блее 200 гб. Работа ПО была на столько медленной, что компания рассматривала вариант вывода сотрудников в третью смену!!! Решение было это начать работу с нуля т.е. с чистой БД (можете себе только представить какие это имело последствия). Так как не дилер не медок ничего путного посоветовать не смогли. Теперь что касается работы БД на Oracle!
Вот цитата:
Festy30 писав:С этим боротся не приходится, поставили винт на 320 гигов и нет проблем, дальше чтобы база не росла архивируем НН.
Объясните в чем принципиальная разница работы между oracle и фб? Да, oracle быстрее работает на БД большего размера. НО при этом она так же растет, и ее так же надо "подрезать", и делать это надо модулем который КРИВО работает. Т.е. по сути покупка oracle не решает основной проблем с медком, кроме регламентного обслуживание БД, допустим, не раз в квартал, а раз в полгода (в зависимости от количества НН).

И Вы данный факт оправдываете з\п разработчиков в 4-6к грн ? Да у ж верно Вы сказали:
priup писав:Не , ну чё за страна, блин............
P.S. ИМХО то как "мдековцы" предлагают компаниям с большим объемом документов покупки oracle, и не желание "допиливать" работу с ФБ. Создается впечатление, что кто-то имеет % с продаж oracle :roll:

Колпаков Б.И.
Повідомлень: 8802
З нами з: 29 липня 2011, 14:59
Звідки: Украина, Донецкая область, Бахмут
Контактна інформація:

Re: Померяемся?

Повідомлення Колпаков Б.И. » 01 липня 2015, 17:42

+1 к Проблеме!
Есть база, не такая большая, ~ 3,5 ГБ, работает на последней версии ФБ в режиме классик, база без ошибок - это подтверждает лог создание РК в менеджере архива программы, но РК типа *.zbk не создается.
База передавалась разработчику, проблема решена не была. Вопрос уперся в процесс Медка.

Inkognito
Повідомлень: 1070
З нами з: 14 січня 2012, 14:26

Re: Померяемся?

Повідомлення Inkognito » 07 липня 2015, 16:27

На других форумах негативные отзывы чистятся ежедневно ;)
Здесь просто забили на форум, поэтому нет ни его поддержки, ни удаления негативных комментариев. Вам круто повезло, - на других форумах Вас бы уже давно забанили 8-) А так да... не хотят сделать нормальное ПО, даже когда предлагают кучу прекрасных решений. Парадокс! :o

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Померяемся?

Повідомлення Ktoia » 07 липня 2015, 17:28

GreN писав:На сервер приложений поставлю visual studio и в режиме дебага подключусь к процессу сервера приложений, ждите новых занимательных сообщений :)
Есть что нового ?

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Померяемся?

Повідомлення Ktoia » 31 серпня 2015, 14:31

GreN писав: Судя по проведенным тестам проблема не в СУБД, а в сервере приложений, Oralce использует другой клиент в сервере приложений этим объясняется его быстродействие, ели разработчики допилсят сервер приложений то и на Firebird будет все ок))))))))
апну темку! есть новости по этой проблеме ?

AllexL
Повідомлень: 47
З нами з: 19 грудня 2011, 20:16
Звідки: Kyiv

Re: Померяемся?

Повідомлення AllexL » 05 листопада 2015, 17:48

Доброго времени суток, коллеги .
Смотрели ли разработчики на новые версии библиотеки? Актуальнауже Version 4.8.0.0 от September 14, 2015, в то время как
fireBirdSql_version.jpg
fireBirdSql_version.jpg (33.68 Кіб) Переглянуто 32729 разів
Или GreN - зря старался?

AllexL
Повідомлень: 47
З нами з: 19 грудня 2011, 20:16
Звідки: Kyiv

Re: Померяемся?

Повідомлення AllexL » 19 лютого 2016, 16:40

Вчера вышла версия библиотеки Firebird ADO.NET Data Provider 4.10.0.0
У нас еще 2.5.1. Может, не стОит заставлять больших клиентов покупать Oracle? обойдемся переходом на 4.10?

Tim
Повідомлень: 18
З нами з: 19 січня 2015, 22:09

Re: Померяемся?

Повідомлення Tim » 19 жовтня 2016, 00:38

Апну темку. Ниже под спойлером рекомендации от Database Analyst 3.0 (IBAnalyst) :twisted: Интересно, когда наступит счастье?)
| Показать
Database Analyst 3.0 (IBAnalyst) build 3.0.2.4, 19.10.2016 0:21:58
Database: ZVIT.FDB

Your database is running 102 days, and average workload is ~243886
transactions per day.

Sweep interval is 20000, and automatic sweep may start 12 times per
day. If you encounter periodical performance slowdown, set sweep
interval to 0 (gfix -housekeeping 0). This will turn off automatic
garbage collection and increase performance. If no, leave sweep
interval as is.

Current database page size is 8192 bytes.

· There are indices (2) with outdated statistics in database. This
can force optimizer to create incorrect query plans. You should
refresh index statistics periodically using set statistics index
<index_name> command for each non-unique index in database, or to use
some tool (HQBird, FBDataGuard) to recompute index selectivity.

Your database have 7 tables fragmented with blobs (see
"Tables fragmented by blobs" list below). Increasing page size can
make these tables much fragmented than now, and some other tables
that have blob fields with data less than new page size can became
fragmented too.


--------------------------------------------------------
Fragmented tables count: 1.
Fragmented tables can slowdown performance. You can monitor listed
tables - if fragmentation will be worse in the course of time, you
need to make backup/restore. Here is the list of tables with data
greater than 200 kilobytes and average fill less than 60%.

FORMPRTUSR : 59%, Records 8865, Pages 76

--------------------------------------------------------
Tables fragmented by blobs count: 7.
Blobs stored in these tables are less than page size (8192), and
since blobs fit at data pages (with records) they "dilutes" records,
so table data became very fragmented. If there are lot of records,
and queries read column data without blobs, such record fragmentation
can cause low performance for natural scans, joins or aggregates. You
can only move these blobs into additional tables, linked with
original as 1-1. Don`t set bigger page size for this database, it can
only slowdown queries that access these tables.

Here is the list of tables that fragmented by blobs:

Table Records Estimated records Real avg.fill

CARDJOURNALOPER 3268563 56670400 3%
CERTIF 20929 125045 14%
DOCSIGN 814986 8302531 6%
DOCSIGNNATIVE 11768 48757 14%
GOVQRY 6429 60189 7%
RDCARD 903 2543 30%
SIGNIMGSPR 32242 356774 6%

--------------------------------------------------------
Bad indices count: 46.
By `bad` we name indices with many duplicate keys (90% of all keys)
and big groups of equal keys (30% of all keys). Big groups of equal
keys slowdown garbage collection - MaxEquals here is % of max groups
of keys having equal values. Index search for such an index is not
efficient. You can drop such indices (if they are not on FK
constraints).

Index ( Relation) Duplicates MaxEquals
ADDRBOOK_IDX2 ( ADDRBOOK) : 100%, 100%
ADDRBOOK_IDX3 ( ADDRBOOK) : 100%, 55%
IDTASK2 ( CALFORMS) : 96%, 68%
CARD_FORM ( CARD) : 100%, 47%
CARD_IDX2 ( CARD) : 100%, 100%
CARD_IDX3 ( CARD) : 100%, 99%
CARD_IDX4 ( CARD) : 100%, 96%
CARD_IDX6 ( CARD) : 100%, 99%
CARD_IDX8 ( CARD) : 100%, 100%
CARD_IDX_GRPID ( CARD) : 99%, 95%
CARD_PDFEXPSTT_IDX ( CARD) : 100%, 100%
FK_CARD ( CARD) : 100%, 77%
CARDJOURNALOPER_ID ( CARDJOURNALOPER) : 100%, 100%
CARDJOURNALOPER_IDX4 ( CARDJOURNALOPER) : 100%, 61%
CARDUREAD2_IDX4 ( CARDUREAD2) : 100%, 83%
CARDUREAD2_IDX5 ( CARDUREAD2) : 100%, 99%
CARDUREAD2_IDX6 ( CARDUREAD2) : 100%, 100%
FE0406C01_TAB1_OTK ( FE0406C01_TAB1) : 100%, 92%
FE0406C01_TAB1_ZO ( FE0406C01_TAB1) : 100%, 83%
FJ0147101_TAB1_CARD ( FJ0147101_TAB1) : 100%, 89%
FK_FJ0147101_TAB1 ( FJ0147101_TAB1) : 100%, 89%
FJ1201002_MAIN_IDX2 ( FJ1201002_MAIN) : 100%, 48%
FJ1201002_MAIN_NAKL_TYPE ( FJ1201002_MAIN) : 100%, 81%
FJ1201002_MAIN_RECNO ( FJ1201002_MAIN) : 100%, 100%
FJ1201002_MAIN_RSTCODE ( FJ1201002_MAIN) : 100%, 100%
FJ1201002_MAIN_RSTTYPE ( FJ1201002_MAIN) : 100%, 54%
FJ1201202_MAIN_IDX1 ( FJ1201202_MAIN) : 100%, 98%
FJ1201202_MAIN_IDX2 ( FJ1201202_MAIN) : 100%, 53%
FJ1201202_MAIN_NAKL_TYPE ( FJ1201202_MAIN) : 100%, 98%
FJ1201202_MAIN_RECNO ( FJ1201202_MAIN) : 100%, 100%
FJ1201202_MAIN_RSTCODE ( FJ1201202_MAIN) : 100%, 100%
FJ1201202_MAIN_RSTTYPE ( FJ1201202_MAIN) : 100%, 57%
FJ1400101_TAB2_IDX3 ( FJ1400101_TAB2) : 100%, 99%
FK_FORMCLS2 ( FORMCLS) : 100%, 71%
FORMPRT_IDX2 ( FORMPRT) : 98%, 86%
GOVQRY_IDX2 ( GOVQRY) : 100%, 80%
NUMHBNPBIDX ( HBNPB) : 100%, 100%
HBPARTNER_IDX3 ( HBPARTNER) : 100%, 54%
NUMIDX65 ( HBSTREET) : 100%, 100%
FK_J0147102_TAB1 ( J0147102_TAB1) : 99%, 32%
J0147102_TAB1_IDX1 ( J0147102_TAB1) : 99%, 32%
IDX_LOGEVENT_CARD_TYPE ( LOGSEVENT) : 100%, 85%
LOGSEVENT_IDX1 ( LOGSEVENT) : 100%, 85%
LOGSEVENT_IDX2 ( LOGSEVENT) : 100%, 100%
FK_PHYSPERSONS ( PHYSPERSONS) : 100%, 98%
PHYSPERSONS_IDX3 ( PHYSPERSONS) : 100%, 98%

--------------------------------------------------------
Useless indices count: 9.
Useless indices have only 1 key value. I.e. indexed column(s) have
only one value for all rows in table. Thus, index search using this
index will unesessary read index pages from disk. You can drop these
indices, if they are not FKs.

Index ( Relation) Equal Keys
CARD_IDX8 ( CARD) : 1224456
CARD_PDFEXPSTT_IDX ( CARD) : 1224456
CARDJOURNALOPER_ID ( CARDJOURNALOPER) : 3268563
CARDUREAD2_IDX6 ( CARDUREAD2) : 1780443
FJ1201002_MAIN_RECNO ( FJ1201002_MAIN) : 857584
FJ1201002_MAIN_RSTCODE ( FJ1201002_MAIN) : 857584
FJ1201202_MAIN_RECNO ( FJ1201202_MAIN) : 348701
NUMHBNPBIDX ( HBNPB) : 1266
NUMIDX65 ( HBSTREET) : 1856

--------------------------------------------------------
Empty tables count: 358.
Listed tables have 0 records. Maybe there are no records now, maybe
these tables reserved for future use of your applications, or they
are global temporary tables (InterBase 7.5-XE3, or Firebird 2.1) with
transaction context,but maybe you just forgot about these tables, and
they can be dropped.

ABFOLDERS
ABLINKS
ACCESSTOFORMS
ACTIONLOG
ACTIONTYPES
ADDFUNC
ANREPORTS
ANSWKVT
ARCHIVE_ACTIVE
BJTPLTSET
CALSTATUS
CALTASKS
CALTASKSUSR
CARDJOURNAL
CARDJOURNALTYPE
CARDLOCKS
CARDSIGNSTT
CB021103
CDATA
CERTIF_LINK
CFGNMR
CHANGEDFLD
CONSOLIDATE
CONS_DOCS
CORPDEPTFORM
CORPDEPTTERM
CORPFLDCONSHIST
CORPFLDNAMEIDX
CORPTABNAMEIDX
CURRUSERS
DKUADDR
DMS20101_MAIN
DMS20101_TAB1
DMS30101_MAIN
DMS30101_TAB1
DOCOUTERBINDING
DOCRESLINKS
DOCSIGNRNN
DOGMAIN
DOGOPER
DOGOPERSPEC
DOGTMPLACCESS
DOGTMPLCMPL
DOGTMPLUSR
DPI04001_MAIN
DPI04001_TAB1
DPI05001_MAIN
DPI05001_TAB1
DPI06001_MAIN
DPI06001_TAB1
DPI20101_MAIN
DPI20101_TAB1
DPI20201_MAIN
DPI20201_TAB1
DPI20301_MAIN
DPI20301_TAB1
DSGCATFUNC
DSGFUNC
DSGFUNCPARAMS
DSGPARAMTYPES
EXPORTEDPDFDOC
EXPRESULT
FDMU_CP
FDMU_CUR_FIL
FDMU_HDOCH
FDMU_UCHRED
FDMU_UEMIS
FDMU_UGUPR
FDMU_UHOLD
FDMU_UPUPR
FDMU_USTATUT
FDMU_UVIPIS
FDMU_UZAST
FDOG0000P_MAIN
FDOG0000P_TAB1
FDOG00101_MAIN
FDOG00101_TAB1
FE0400C01_TAB1
FE0402C01_MAIN
FE0403C01_MAIN
FE0407C01_MAIN
FE0407C01_TAB1
FE0408C01_MAIN
FE0408C01_TAB1
FE0409C01_MAIN
FE0409C01_TAB1
FE0500C_MAIN
FE0500D_MAIN
FE0500D_TAB1
FE0501C_MAIN
FE0501D_MAIN
FE0502C_MAIN
FE0502D_MAIN
FE0502D_TAB1
FE0503C_MAIN
FE0503D_MAIN
FE0504C_MAIN
FE0504D_MAIN
FE0505C_MAIN
FE0505D_MAIN
FE0506C_MAIN
FE0506D_MAIN
FE0600C_MAIN
FE0600D_MAIN
FE0600D_TAB1
FE0601C_MAIN
FE0601D_MAIN
FE0601D_TAB1
FE0602C_MAIN
FE0602D_MAIN
FE0602D_TAB1
FE0603C_MAIN
FE0603D_MAIN
FE0603D_TAB1
FE0604D_MAIN
FE0604D_TAB1
FE0700C_MAIN
FE0700D_TAB1
FE0701C_MAIN
FE0701D_MAIN
FFPEN5_MAIN
FFPEN5_TAB1
FFPEN6_MAIN
FFPEN6_TAB1
FJ0200515_MAIN
FJ0200515_TAB1
FJ0200515_TAB2
FJ0209701_MAIN
FJ0209701_TAB1
FJ0209801_MAIN
FJ0209801_TAB1
FJ0209801_TAB2
FJ0215108_MAIN
FJ0215108_TAB1
FJ0215108_TAB2
FJ0215108_TAB8
FJ1201002_RVS
FJ1201102_MAIN
FJ1201102_TAB1
FJ1201501_TAB2
FJ1400101_REG
FJ1400101_SND
FJ1401902_MAIN
FJ1401902_TAB
FJ1402601_MAIN
FJ1402701_MAIN
FJ1402701_TAB1
FJ3040410_MAIN
FMOZ06601_TAB1
FMOZ06601_TAB2
FMOZ06601_TAB3
FOR1CFJ1310101
FORMFR
FORMPLT
FORM_EXCHANGE
FP0402B01_MAIN
FP0403B01_MAIN
FP0404B01_MAIN
FP0408B01_MAIN
FP0408B01_TAB1
FP0409B01_MAIN
FP0409B01_TAB1
FP0410B01_MAIN
FP0410B01_TAB1
FRTMPLUSR
FS0400111_TAB1
FS0400111_TAB2
FS0400111_TAB3
FSPP_MAIN
FSPP_SRC
FSPP_TAB1
GATEJOURNAL
GOVPOSTING
HBACCNUMNDS
HBBUDGETLGOT
HBBUDGETTYPE
HBDEPART
HBDOCUMENT
HBEMPD
HBEMPLOYEE
HBFSS
HBGOODS
HBGOODSGRP
HBKISE
HBLIST_ACTIVITIES
HBNOTPR
HBOPERTYPE_DOD6
HBPARTNERHISTORY
HBPDV
HBPLTSTT
HBPTO
HBRENTCONTRACT
HBRRO
HBSENDROUTE
HBSHARERS
HBSTAT
HBSTATCMD
HBTAXCAR
HBTAXER
HBTNAME
HBTYPE_JS_COMPANY
HBUSR
HBVALUES
HBVO
HISTORY
IAUTONUMNST
IMAINKEYS
IMPRNNDOCS
IMPTMPLS
IPACK
IPLTKEYS
ISYSCFG
IUSERACC
IUSERACCGRP
IUSERACCGRPNM
IUSERACCNM
IUSERORG
IUTABFLD
IUTEMPLATE
IUTMPLPKDC
IUTMPLTST
IWGACC
JRNSUBSCR
JRNSUBSCRSETT
KCPFR
LINCK_NUMBER
LOGSEVENTUSR
LPU_SECT
LPU_SECT_BED
LPU_SECT_PERSONS
LSVDO
MAIL
MAILFOLDERS
MAILMESSAGES
MEDOCONLINE
NAKLREG
NBUPARAMS
NBUSTATDIM
NBUSTATFILE
NDSPLTSTT
ORGACC
ORGFND
ORGKVED
ORGNPF
P2000201_MAIN
P2000201_TAB1
PACKET
PACKETCNT
PACKSTATUS
PARTINFO
PARTSIGN
PD800304_MAIN
PD800304_TAB1
PD800304_TAB10
PD800304_TAB11
PD800304_TAB12
PD800304_TAB13
PD800304_TAB14
PD800304_TAB15
PD800304_TAB16
PD800304_TAB17
PD800304_TAB18
PD800304_TAB19
PD800304_TAB2
PD800304_TAB20
PD800304_TAB21
PD800304_TAB22
PD800304_TAB23
PD800304_TAB24
PD800304_TAB3
PD800304_TAB4
PD800304_TAB5
PD800304_TAB6
PD800304_TAB7
PD800304_TAB8
PD800304_TAB9
PERSACC
PERSACCDESC
PFUCERT
PHYSPERSONSEXP
PHYSPERSONSIMG
PJMAINDATA
PREFROWS
PRNDOCQRY
PROCURATIONDOC
QLSDATA
QLSQRY
RDAPPENDIX
RDAPPENDIX_SIGN
RDCARD_HISTORY
RDINPROCEXTSTT
RDNOTE
RDOPERS
RDPARTNACC
RDTMPLOPERS
RDTMPLOPREFS
RDUSERTMPLLINKS
REJECTEDDOC
RELATION_ROLE_ORG_SUBSYSTEM
REL_OFGP
ROLEACCESS
RTFCARDTABLES
SIGNFILE_FOLDER
SIGNFILE_P7S
SIGNSETTINGS
SOPARAMS
SUBSYSTEM_SETTINGS
TAXINSPADDR
TMP_NOFORMCODE
TMP_PARTNER
UNRDSOKVT
USERPLT
VATAMOUNTS
WAITINGREVOCATION
WFTASKS
X1
XKB
XMLSPR
XMPR
XRSTTP
ZRP1CTMPL
ZRPBOARD
ZRPBOARDBYDAY
ZRPCALCFUND
ZRPCALCREST
ZRPCALCRETURN
ZRPCALCSTORNO
ZRPCALCSTORNODAYS
ZRPCALCTAX
ZRPCALCVO
ZRPFUNDPOSTING
ZRPGRAPHICWRK
ZRPHBENTOP
ZRPHBEVZCORR
ZRPHBGRAPHICHAND
ZRPHBGRAPHICPLAN
ZRPINDFIX
ZRPJOBS
ZRPLICACCOUNT
ZRPLICCATCH
ZRPLICCATZO
ZRPLICCHARGE
ZRPLICDEDUCATE
ZRPLICFUNDS
ZRPLICGRAPHIC
ZRPLICHISTORY
ZRPLICINDPRICES
ZRPLICPILGI
ZRPLICSENIORITY
ZRPMIDDLEZPCOEFF
ZRPMIDSUM
ZRPPHYSPERSADR
ZRPPOSTING
ZRPPOSTINGF
ZRPRECALC
ZRPUPDATE
ZRPVERCLOSE
ZRPVOUPD

--------------------------------------------------------
Generated from IBSurgeon technical support knowledgebase.

You can request IBSurgeon technical support here: http://www.ib-aid.com/services/optimization

AllexL
Повідомлень: 47
З нами з: 19 грудня 2011, 20:16
Звідки: Kyiv

Re: Померяемся?

Повідомлення AllexL » 19 жовтня 2016, 09:58

Tim писав:Апну темку. Ниже под спойлером рекомендации от Database Analyst 3.0 (IBAnalyst) :twisted: Интересно, когда наступит счастье?)
Вероятно, все эти проблемы имеют место быть. Но проблема не в базе данных, имхо. Application server еще оптимизировать и оптимизировать.

AllexL
Повідомлень: 47
З нами з: 19 грудня 2011, 20:16
Звідки: Kyiv

Re: Померяемся?

Повідомлення AllexL » 25 липня 2017, 09:15

Вот вы только не смейтесь, но.....
Рассматривается централизации МЕДОКа: количество пользователей 250+, 16 предприятий по 3-5 филиалов на каждом + огромная головная контора, через которую идет основной поток НН. Повідомлень про прием на работу персонала, ЕСВ и прочих околозарплатных отчетов - уйиа, т.к. персонал исчисляется десятками тысяч (больше 50 000 точно)

С железом - не ахти как, как и с терминальными лицензиями. Могут выделить лицензий на 1, максимум - 2 терминалки. Кто с каким объемом пользователей работал? какие будут идеи?

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Померяемся?

Повідомлення priup » 25 липня 2017, 09:22

AllexL писав:
25 липня 2017, 09:15
Вот вы только не смейтесь, но.....
.................... какие будут идеи?
Жалко мне ВАС!!! Просто, по человечески..............
Очень похоже поступила ДФС с 1 июля: риски внедрила , а железо тоже............

Відповісти

Повернутись до “Побажання”