[ОТВЕТИТЬ]
01.11.2009 20:58
Starter
 
Установили 1.27.1 (впрочем, 1.27.2 тоже пробовали) и обнаружилась неприятная особенность - заполнение накладных ценами последнего прихода отрабатывает ооочень медленно (15 позиций - около 5 минут, 30 - около получаса). Поддержка сказала что нужно прогнать полный сбор статистики по базе. Прогнали все задания что можно (ппи, чсс, псс) - ничего не помогает. Может кто уже с этим сталкивался ? что еще прогнать/поменять ? И влияет ли на скорость отбора расчет статистики в модуле администратора Аналитика/статистика ?

ЗЫ. Oracle 9.2.0.1.0
ЗЗЫ. Раньше стояла 1.26.4 - там подобного не наблюдалось.
02.11.2009 04:38
Vovantus
 
Цитата:
Starter ЗЫ. Oracle 9.2.0.1.0
э-э-э, а не старая версия? Кажись, есть 9.2.0.8.0, может обновиться, для начала?
02.11.2009 07:04
OlegON
 
Цитата:
Vovantus есть 9.2.0.8.0, может обновиться, для начала?
Однозначно. И статистике из заданий не доверять.
02.11.2009 09:58
Starter
 
Предыдущую версию не там посмотрел - в Manager Console, Help/About oracle. Ставили 9.2.0.1.0, потом патч прогоняли (было правда это 2 года назад). Патч 9.2.0.8.0 установить можно, но странно, что это вылезает исключительно после установки СМ 1.27.1 и 1.27.2 (в двух магазинах).
И если не доверять статистике из СМ, то какую еще рассчитать ? Может поделитесь ссылкой где можно почитать как ее из оракла рассчитать ?
В оракле, к сожалению, не силен, иначе бы и не спрашивал...

Просто были подозрения что СП что-то подработал в новой версии и возможно существуют какие-то стандартные действия, которые необходимо проделать ? Кто 1.27.хх ставил с этой проблемой не сталкивался ?
02.11.2009 10:03
Mtirt
 
У нас 1.027 - проблемы нет.
02.11.2009 10:06
Vovantus
 
Цитата:
Starter И если не доверять статистике из СМ, то какую еще рассчитать ? Может поделитесь ссылкой где можно почитать как ее из оракла рассчитать ?
Например, следующим образом. Создаём файлик stat_get.sql . В него помещаем следующий код:
Код:
set feedback off;
set heading off;
set termout off;
set linesize 1000;
set trimspool on;
set verify off;
spool c:\Sql\Stat_Run.sql;

select 'ANALYZE TABLE '||OWNER||'.'||TABLE_NAME||' DELETE STATISTICS;'
    from dba_tables 
    where temporary='Y' and owner='SUPERMAG'
union all
select 'ANALYZE INDEX '||OWNER||'.'||INDEX_NAME||' DELETE STATISTICS;'
    from dba_indexes 
    where temporary='Y' and owner='SUPERMAG'
union all
select 'ANALYZE TABLE '||OWNER||'.'||TABLE_NAME||' COMPUTE STATISTICS;'
    from dba_tables 
    where tablespace_name in ('USERS','INDX') and owner='SUPERMAG'
union all
select 'ANALYZE INDEX '||OWNER||'.'||INDEX_NAME||' COMPUTE STATISTICS;'
    from dba_indexes 
    where tablespace_name in ('USERS','INDX') and owner='SUPERMAG';

prompt exit;
prompt /;
spool off;
set feedback on;
set heading on;
set termout on;
set linesize 100;
exit
далее, выполняем следующую команду:
Код:
qlplus.exe sys/qqq@DATABASE @c:\Sql\stat_get.sql
Само собой, правим расположение файлов и данные для подключения к базе. После выполнению, в каталоге c:\Sql появится файлик stat_run.sql, запускае его на выполнение через следующуюкоманду:
Код:
qlplus.exe sys/qqq@DATABASE @c:\Sql\stat_run.sql
и ждём, пока задача отработает.
02.11.2009 12:11
Starter
 
Попробуем, спасибо. Сейчас юзеров повыгоняем, посмотрим.
Заодно базу в СП отправили, по результатам отпишусь.
02.11.2009 14:03
Starter
 
Скрипт прогнали. база 12 гб, в сжатом виде 1.4 Гб, отрабатывал минут 40. Затем запустили супермаг, проверили - толку никакого. накладная 340 строк, уже минут 20 рассчитывает, конца процессу не видно.
Может есть еще какие мысли ?
02.11.2009 14:27
OlegON
 
Выдрать запрос, который тормозит и его план. Сравним.
02.11.2009 14:45
Starter
 
Это то ?
Oracle SQL Explain Plan 2 Ноябрь 2009 г. 14:47:57 GMT+03:00

Target:
KNTROICK

Version: Oracle 9.2.0.7.0

Database: KNTROICK

Schema: SUPERMAG

Date: 02.11.2009 3:00:00


SQL Statement:

SELECT sp.specitem, sc.doctype, sc.docid, sc.specitem specitem_src,
sc.itemprice, sc.itempricenotax
FROM smspec sp, smspec sc
WHERE sp.doctype = :b1
AND sp.docid = :b2
AND (:b3 = '0'
OR nvl(sp.itemprice, 0) = 0)
AND sc.article = sp.article
AND sc.doctype || sc.docid = (SELECT substr(max(to_char(d1.createdat,
'YYYYMMDD') || d1.doctype || d1.id),
9)
FROM smspec s1, smdocuments d1
WHERE s1.doctype = d1.doctype
AND s1.docid = d1.id
AND d1.createdat <= :b4
AND d1.docstate = 3
AND d1.doctype IN ('WI', 'PO')
AND d1.opcode IN (0, 13)
AND s1.article = sp.article
AND d1.locationto IN (SELECT id
FROM ttshoplist)
AND (d1.doctype != :b1
OR d1.id != :b2))
AND sc.specitem IN (SELECT max(s3.specitem)
FROM smspec s3
WHERE s3.doctype = sc.doctype
AND s3.docid = sc.docid
AND s3.article = sc.article)


Optimizer Mode Used:

COST ALL ROWS (optimizer: CHOOSE)

Total Cost:

162

Execution Steps:

Step # Step Name
20 SELECT STATEMENT
19 FILTER
18 SORT [GROUP BY]
17 FILTER
13 NESTED LOOPS
11 NESTED LOOPS
8 NESTED LOOPS
5 NESTED LOOPS
2 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
1 SUPERMAG.SMCSPEC_DISPLAYPOS INDEX [RANGE SCAN]
4 INLIST ITERATOR
3 SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN]
7 SUPERMAG.SMDOCUMENTS TABLE ACCESS [BY INDEX ROWID]
6 SUPERMAG.SMCDOCUMENTS_PK INDEX [UNIQUE SCAN]
10 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
9 SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN]
12 SUPERMAG.TTCSHOPLIST_PK INDEX [UNIQUE SCAN]
16 SORT [AGGREGATE]
15 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
14 SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN]

Step # Description Est. Cost Est. Rows Returned Est. KBytes Returned
1 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMCSPEC_DISPLAYPOS. 3 7 --
2 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 4 1 0,032
3 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMSPEC_ART. 2 26 0,482
4 This plan step loops through the query's IN list predicate, executing its child step for each value found.
5 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 6 3 0,152
6 This plan step retrieves a single ROWID from the B*-tree index SMCDOCUMENTS_PK. -- 1 --
7 This plan step retrieves rows from table SMDOCUMENTS through ROWID(s) returned by an index. 1 1 0,021
8 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 9 1 0,072
9 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMSPEC_ART. 2 144 --
10 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 146 1 0,036
11 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 155 1 0,108
12 This plan step retrieves a single ROWID from the B*-tree index TTCSHOPLIST_PK. -- 4 084 51,848
13 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 155 28 3,391
14 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMSPEC_ART. 3 1 --
15 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 4 1 0,021
16 This plan step accepts a row set (its only child) and returns a single row by applying an aggregation function. -- 1 0,021
17 This plan step accepts multiple sets of rows. Rows from the first set are eliminated using the data found in the second through n sets.
18 This plan step accepts a set of rows from its child node, and sorts them into groups based on the columns specified in the query's GROUP BY clause. 158 1 0,121
19 This plan step accepts a set of rows from its child node, eliminates some of them, and returns the rest.
20 This plan step designates this statement as a SELECT statement.
02.11.2009 15:09
OlegON
 
А с чего ты взял, что это самый тормозной? Цена его в 162 как-то озадачивает
02.11.2009 15:21
OlegON
 
Может, кто-то выложит свой для сравнения? У меня нестандартная структура
Код:
-----------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                 | Name                  | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                          |                       |     1 |   119 |   127   (9)| 00:00:01 |       |       |
|*  1 |  FILTER                                   |                       |       |       |            |          |       |       |
|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID       | SMSPEC                |    16 |   544 |    26   (0)| 00:00:01 |       |       |
|   3 |    NESTED LOOPS                           |                       |    16 |  1904 |   103  (10)| 00:00:01 |       |       |
|   4 |     NESTED LOOPS                          |                       |     1 |    85 |    76  (14)| 00:00:01 |       |       |
|   5 |      VIEW                                 | VW_SQ_1               |     1 |    55 |    74  (14)| 00:00:01 |       |       |
|   6 |       HASH GROUP BY                       |                       |     1 |    73 |    74  (14)| 00:00:01 |       |       |
|   7 |        TABLE ACCESS BY GLOBAL INDEX ROWID | SMSPEC                |     9 |   252 |     2   (0)| 00:00:01 | ROWID | ROWID |
|   8 |         NESTED LOOPS                      |                       |     1 |    73 |    73  (13)| 00:00:01 |       |       |
|   9 |          NESTED LOOPS                     |                       |     1 |    45 |    71  (13)| 00:00:01 |       |       |
|  10 |           TABLE ACCESS FULL               | TTSHOPLIST            |     1 |    13 |     2   (0)| 00:00:01 |       |       |
|* 11 |           TABLE ACCESS BY INDEX ROWID     | SMDOCUMENTS           |     6 |   192 |    71  (13)| 00:00:01 |       |       |
|  12 |            BITMAP CONVERSION TO ROWIDS    |                       |       |       |            |          |       |       |
|  13 |             BITMAP AND                    |                       |       |       |            |          |       |       |
|* 14 |              BITMAP INDEX SINGLE VALUE    | SMDOCUMENTS_LOCTOB    |       |       |            |          |       |       |
|  15 |              BITMAP CONVERSION FROM ROWIDS|                       |       |       |            |          |       |       |
|  16 |               SORT ORDER BY               |                       |       |       |            |          |       |       |
|* 17 |                INDEX RANGE SCAN           | SMDOCUMENTS_CREATEDAT |  8197 |       |     5   (0)| 00:00:01 |       |       |
|* 18 |          INDEX RANGE SCAN                 | SMCSPEC_DISPLAYPOS    |     1 |       |     2   (0)| 00:00:01 |       |       |
|  19 |      PARTITION LIST SINGLE                |                       |     1 |    30 |     2   (0)| 00:00:01 |   KEY |   KEY |
|  20 |       TABLE ACCESS BY LOCAL INDEX ROWID   | SMSPEC                |     1 |    30 |     2   (0)| 00:00:01 |     6 |     6 |
|* 21 |        INDEX RANGE SCAN                   | SMSPEC_ART            |     1 |       |     2   (0)| 00:00:01 |     6 |     6 |
|  22 |     PARTITION LIST ALL                    |                       |    16 |       |    14   (0)| 00:00:01 |     1 |     9 |
|* 23 |      INDEX RANGE SCAN                     | SMSPEC_ART            |    16 |       |    14   (0)| 00:00:01 |     1 |     9 |
|  24 |   SORT AGGREGATE                          |                       |     1 |    26 |            |          |       |       |
|  25 |    PARTITION LIST SINGLE                  |                       |     1 |    26 |     3   (0)| 00:00:01 |   KEY |   KEY |
|  26 |     TABLE ACCESS BY LOCAL INDEX ROWID     | SMSPEC                |     1 |    26 |     3   (0)| 00:00:01 |   KEY |   KEY |
|* 27 |      INDEX RANGE SCAN                     | SMSPEC_ART            |     1 |       |     2   (0)| 00:00:01 |   KEY |   KEY |
-----------------------------------------------------------------------------------------------------------------------------------
02.11.2009 15:24
Starter
 
Enterprise Manager Console, Sessions, SQL - брал оттуда. собственно единственный пользователь, единственная сессия... оттуда и взял.
02.11.2009 15:29
OlegON
 
Она хотя бы active была? Полоска прогресса бежала? Легкий SQL.
02.11.2009 15:49
Starter
 
Active. полоски прогресса там не видел, смотрел в свойствах сессии. Может не там смотрел ?
02.11.2009 16:21
OlegON
 
Думаю, что просто один и тот же запрос много раз посылается. Если бы он тормозил, то цена была бы выше. А, собственно, как заполняется ценами? Вроде два способа есть - Функции - Заполнить ценами и Проставить основания - Проставить цены (пишу по памяти, могу ошибиться в наименовании). MTirt, у тебя каким образом и сколько по времени заполняется (какое кол-во в накладной)?
02.11.2009 16:31
Mtirt
 
Ну у меня накладную на 340 позиций найти сложно, но 7 строк, "Простановка оснований" - секунд 10-15.
03.11.2009 06:58
OlegON
 
Ну на самом деле, если 10 секунд увеличить в 50 раз, то получим минут 20? На 340 позиций... А их бывает по 700... И опять же, каким способом? Я смогу попробовать только в среду.
03.11.2009 11:46
Starter
 
Цитата:
OlegON Ну на самом деле, если 10 секунд увеличить в 50 раз, то получим минут 20? На 340 позиций... А их бывает по 700... И опять же, каким способом? Я смогу попробовать только в среду.
А бывает и по 20 000 (инвентаризация) :(
Способ заполнения - в ПН или РН функции/заполнить документ ценами последнего прихода, либо там же кнопка цены/заполнить документ ценами последнего прихода. результат один и тот же.
что печально - базу в СП выгрузил еще вчера, в 12. Весь день не могли базу развернуть, а сейчас говорят, что что то скажут только к понедельнику. это через неделю после обращения. весело живут, ничего не скажешь... Может все же есть еще какие предложения у гуру ?
что касается запроса и что он выполняется много раз (возможно для каждой строки документа) - очень может быть, но это проблема скорее программы, а не оракла, думаю мы бы не первые с этим столкнулись... тем более эта бага и в 1.27.1 сп3, и в 1.27.2
Может кто еще у себя проверит - есть ли тормоза при таком заполнении ценами ?
1.27.2 - запрос такой же. цена правда 199.
сервер помощнее, накладная 36 строк - всего лишь за полчаса выполняет %(
Если смотреть через manager console, то для этой сессии
показатели - CPU - 24, I/O - Phys Reads 0, I/O Logical reads - 199124079 (эта сессия явно лидер по этому показателю).
03.11.2009 12:14
baggio
 
Давай по порядку:
1. Полная конфа сервера... с дисками и размещением файлов.
2. Ос и все что в памяти крутится...
3. Полная инфа по базе включая init.ora и если есть ORA- в алерте и его...

ИМХО проблема яыно либо в статистике... либо в индексах.. либо в неверно выставленных параметрах в инит.ора...
03.11.2009 12:22
OlegON
 
Я до завтрашнего дня оторван от Супермага, поэтому попробовать не смогу. Но еще раз предложу заполнять ценами через простановку оснований. Будет ли быстрее? И еще раз, кто-нибудь подтвердит, что у него 300 позиций заполняется за какое-то небольшое время? Просто при вале запоросов, думаю, быстрее полусекунды они отстреливаться все равно не должны при такой стоимости.
03.11.2009 13:15
Starter
 
Цены из оснований - так у этих документов оснований то нету. соответственно цены оснований нулевые.


processes = 150
timed_statistics = TRUE
shared_pool_size = 192937984
sga_max_size = 1370040744
large_pool_size = 268435456
java_pool_size = 33554432
spfile = d:\oracle\database\spfileBRO.ora
control_files = c:\oracle\oradata\BRO\control01.ctl, c:\oracle\oradata\BRO\control02.ctl, c:\oracle\oradata\BRO\control03.ctl
db_block_size = 8192
db_cache_size = 838860800
compatible = 9.2.0.0.0
log_buffer = 10485760
db_file_multiblock_read_count = 16
fast_start_mttr_target = 0
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 10800
O7_DICTIONARY_ACCESSIBILITY = TRUE
remote_login_passwordfile = EXCLUSIVE
instance_name = BRO
dispatchers = (PROTOCOL=TCP) (SERVICE=BROXDB)
job_queue_processes = 3
hash_join_enabled = TRUE
background_dump_dest = d:\oracle\admin\BRO\bdump
user_dump_dest = d:\oracle\admin\BRO\udump
core_dump_dest = d:\oracle\admin\BRO\cdump
sort_area_size = 10485760
db_name = BRO
open_cursors = 300
star_transformation_enabled = FALSE
query_rewrite_enabled = FALSE
pga_aggregate_target = 513802240
aq_tm_processes = 1

------------
2x DualCore Intel Xeon 5130, 2000 MHz (6 x 333)
Системная плата Intel Star Lake S5000PSL
память
4089 Мб (DDR2-667 Fully Buffered ECC DDR2 SDRAM)
рейд:
Intel(R) RAID Controller SRCSAS18E
база - рейд 10, 4 SAS диска, WD, 15 К
----
OS: Microsoft Windows Server 2003 R2, Standard Edition 5.2.3790 SP2
из ПО- oracle, supermag, Open office.
в памяти практически ничего нет (стандартные процессы, оракл).
03.11.2009 13:23
OlegON
 
Цитата:
Starter Цены из оснований - так у этих документов оснований то нету. соответственно цены оснований нулевые.
Типа приходы есть, а оснований нету? ;) Попробуй, поэкспериментируй. Не цены из оснований, а "Проставить основания" - там среди опций были и цены.
03.11.2009 15:13
vdm
 
Речь же в основном про приходные.
Не вижу там "проставить основания", это для расходных.

В 1.025.1 такой запрос по функции "Заполнить документ ценами последнего прихода", обе галки в доп. диалоге отключены.

Код:
SELECT sp.specitem, sc.doctype, sc.docid, sc.specitem specitem_src,
       sc.itemprice, sc.itempricenotax
  FROM smspec sp, smspec sc, smdocuments d
 WHERE sp.doctype = :b1
   AND sp.docid = :b2
   AND ((:b3 = '0') OR NVL (sp.itemprice, 0) = 0)
   AND sc.doctype = d.doctype
   AND sc.docid = d.ID
   AND d.createdat <= :b4
   AND d.doctype = 'WI'
   AND d.docstate = 3
   AND d.opcode = 0
   AND sc.article = sp.article
   AND d.locationto IN (SELECT ID
                          FROM ttshoplist)
   AND (:b1 != 'WI' OR d.ID != :b2)
   AND d.ID IN (
          SELECT MAX (d2.ID)
            FROM smspec s2, smdocuments d2
           WHERE s2.doctype = d2.doctype
             AND s2.docid = d2.ID
             AND d2.doctype = 'WI'
             AND d2.docstate = 3
             AND d2.opcode = 0
             AND s2.article = sp.article
             AND d2.locationto IN (SELECT ID
                                     FROM ttshoplist)
             AND (:b1 != 'WI' OR d2.ID != :b2)
             AND d2.createdat IN (
                    SELECT MAX (d1.createdat)
                      FROM smspec s1, smdocuments d1
                     WHERE s1.doctype = d1.doctype
                       AND s1.docid = d1.ID
                       AND d1.createdat <= :b4
                       AND d1.doctype = 'WI'
                       AND d1.docstate = 3
                       AND d1.opcode = 0
                       AND s1.article = s2.article
                       AND d1.locationto IN (SELECT ID
                                               FROM ttshoplist)
                       AND (:b1 != 'WI' OR d1.ID != :b2)))
   AND sc.specitem IN (
          SELECT MAX (s3.specitem)
            FROM smspec s3
           WHERE s3.doctype = d.doctype
             AND s3.docid = d.ID
             AND s3.article = sp.article)
Запрос один и стоимость показывает смешную - 5
740 позиций посчитал за 40сек.
03.11.2009 16:35
Starter
 
Ну если рассматривать шире, то список документов где это широко используется (по крайней мере нами) - РН, ПН, описи, слич. ведомости, расход на производство.
в РН да, основания проставляются, причем если не по результатам товародвижения, а по последнему/первому приходу, то очень быстро.
но это только для РН. для ПН такого пункта нет.

что в версии 1.25.1 отрабатывает быстро - охотно верю, в 1.26.4 и 1.24.6 (стояли до перехода на 1.27.2 и 1.27.1) тоже все срабатывало быстро (ну разве что в инвентаризационных ведомостях где 20-30 тыс. строк - полчаса считал). а накладные до 1000 позиций - максимум минуту-две.
проявилось только после новой версии.
Установил SpotLight, там сделал trace сессии (нажал заполнить ценами прихода), потом trace.
файл могу выложить. а так там же в анализе SQL - первые строки:
SQL ID Elapsed (ms) CPU (ms) Parse Count Execute Count Fetch Count Total Rows Disk IO Logical IO % Total Elapsed Logical IO/Exec Logical IO/Rows CPU/Exec Disk/Exec SQL Statement
4 1525643,03 1486281,25 0 1 0 1 12874 174194294 99,82 174194294,00 174194294,00 1486281,25 12874,00 begin SuperMag.SMDocGetLastIncomePriceFI_WO(:V00001,:V00002); end;
7 559,66 296,88 10 5 0 5 0 1128 0,04 225,60 225,60 59,38 0,00 begin Supermag.SMBeginActionEx(:V00001,:V00002,:V00003,:V00004,:V00005,:V00006,:V00007,:V00008); end;
2 266,78 171,88 0 0 57 56 1213 0 0,02 0,00 SELECT SP.SPECITEM,SC.DOCTYPE,SC.DOCID,S ... FROM SMSPEC SP,SMSPEC SC WHERE SP.DOCTYPE = :b1 AND SP.DOCID = :b2 AND ((:b3 = '0' ) OR NVL(SP.ITEMPRICE,0) = 0 ) AND SC.ARTICLE = SP.ARTICLE AND SC.DO
20 248,26 281,25 15 15 15 15 0 885 0,02 59,00 59,00 18,75 0,00 select max(nvl(option$,0)) from sysauth$ where privilege#=:1 connect by grantee#=prior privilege# and privilege#>0 start with (grantee#=:2 or grantee#=1) and privilege#>0 group by privilege#
54 191,00 250,00 114 57 57 57 0 2743 0,01 48,12 48,12 4,39 0,00 SELECT DS.DocType, DS.DocID, DS.SpecItem ... from SuperMag.SVCardName C where C.Article=DS.Article) as MeasureID,DS.Quantity,DS.ItemPrice, DS.TotalPrice,DS.ItemPriceNoTax,DS.TotalPriceNoTax, DS.ItemPr
148 173,89 187,50 3 3 0 0 0 558 0,01 186,00 62,50 0,00 set role SUPERMAG_MODULE_
03.11.2009 17:15
baggio
 
тогда приходит на ум только одно...
изменили функции
SMDocGetLastIncomePriceFI_WO
или
SUPERMAG_FN_DOC_WO_SET_PRICES

проверь... это код от 1.26.1 sp4
по базе не запускать просто визуаль сверь...

ЗЫ... Олег с какого момента файлы формата *.sql у нас являются некоректными ?
Вложения
Тип файла: rar abcd.rar (633 байт, 73 просмотров)
03.11.2009 18:22
Starter
 
первая функция - один в один такая же, вторую - сравнивать не с чем...
03.11.2009 18:40
baggio
 
Цитата:
Starter первая функция - один в один такая же, вторую - сравнивать не с чем...
Соврал я не функция вторая... роль...
Если функцию не меняли... смотреть всетаки в настройки базы...
а какой у тебя index_cost_adj ?
и на время я бы попробывал sort_area_size уменьшить мегабайт до 4...
чисто интуитивно...
Кстати у тебя только контрольники на С:\?
03.11.2009 19:15
Starter
 
index_cost_adj 100

на C: да, только контрольники. когда базу создавали, случайно туда запихнули. Это в одном магазине, в другом все на D:, там сервер послабее.
03.11.2009 20:52
OlegON
 
Цитата:
vdm Речь же в основном про приходные.
Не вижу там "проставить основания", это для расходных.
Да, я тормознул. У меня похожая проблема с заполнением расходок была. Но то, что в расходку быстро проставляются все таки двигает в сторону испорченного пакета. Его уже ломали где-то на 1025 версии, ничего не могу сказать про новую, увы. Кстати, в спотлайте красным что-нибудь моргает, когда заполнение идет? Не надо только кучу текста выкидывать, неформатируя. Тот приведенный кусок просто пропустил-нечитаемо.


Опции темы


Часовой пояс GMT +3, время: 16:21.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.