|
XML Reports
|
||
|---|---|---|
Участник
Сообщения: 71
|
||
|
А если решить проблему следующим способом?
Таблица: 1. Идентификатор отчета 2. Пользователь 3. Дата последней генерации отчета 4. Параметр отчета 5. Значение параметра По 1 и 2 полю получаем предыдущий отчет и сравниваем параметры При вызове отчета после сравнения сохраняем значения отчета в те же поля. Если этот вариант не очень... пожалуйста ногами не бить..  |
||
| 21.02.2002, 07:57 |
|
|
|
XML Reports
|
||
|---|---|---|
Гость
|
||
|
Ну и самое главное - результат выполнения этого запроса FOR XML мне нужно загнать в поле таблицы или переменную. Как это сделать ?
Вот вам - приговор: \nGuidelines for Using the FOR XML Clause The FOR XML clause is valid only in the SELECT statement and is subject to these limitations: FOR XML is not valid in subselections, whether it is in UPDATE, INSERT, or DELETE statements, a nested SELECT statement, or other statements (SELECT INTO, assignment). For example, subselects as shown in these examples are not supported: Example A SELECT * FROM Table1 WHERE ......(SELECT * FROM Table2 FOR XML RAW) Example B DECLARE @doc nchar(3000) SET @doc = (SELECT * FROM Customers WHERE CustomerID = 'ALFKI' FOR XML RAW) FOR XML is not valid for any selection that is used with a COMPUTE BY or FOR BROWSE clause, for example: SELECT OrderID, UnitPrice FROM [Order Details] ORDER BY OrderID COMPUTE SUM(UnitPrice) BY OrderID GROUP BY and aggregate functions are currently not supported with FOR XML AUTO. For example: SELECT max(price), min(price), avg(price) FROM titles FOR XML AUTO FOR XML is not valid in a SELECT statement used in a view definition or in a user-defined function that returns a rowset. For example, this statement is not allowed: CREATE VIEW AllOrders AS SELECT * FROM Orders FOR XML AUTO However, a statement such as the following is allowed: SELECT * FROM ViewName FOR XML AUTO are allowed. FOR XML cannot be used in a selection that requires further processing in a stored procedure. FOR XML cannot be used with cursors. Generally, FOR XML cannot be used for any selections that do not produce direct output to the Microsoft® SQL Server™ 2000 client. Поэтому - разбирайтесь с ADO... |
||
| 22.02.2002, 07:15 |
|
|
|
XML Reports
|
||
|---|---|---|
Гость
|
||
|
> Прекрасная идея. Надо попробовать. Интересно, а можно ли в таком столбце хранить таблицу, которая в свою очередь тоже будет содержать столбцы-таблицы ?
По идее должно работать. > А как работать с такими столбцами-таблицами на клиенте через ADO ? (я хочу проверку на изменения делать на клиенте, чтобы сервер не перегружать). IMHO никак. Нужно, наверное, выдернуть эту таблицу каким-то SELECT.... Я просто больше программист, чем DBA, потому посмотрел на эту задачу со своей стороны. XML/XSL знаю вдоль и поперек, потому хочу посоветовать взять за основу именно то, что говорят DBA - пробуй как-то через тригера отлавливать изменения, потому как если переносить все на клиента, то все будет зависеть, насколько сложна будет логика сравнения. Сравнивать два XML документа так же невозможно (в идеале), как и две таблицы. Можно только скрипты для таблиц сравнивать <ROOT> <ReportHeader> .... </ReportHeader> <ReportBody> ..... ..... <SubReport1> ..... </SubReport1> ..... </ReportBody> </ROOT> То есть можно, не анализируя подробности, сразу взять кусок Subreport1 и сравнить его с куском Subreport1 нового отчета (чисто как строки), и если там нету дат и порядок тэгов сохранен и все они во всех версиях одинаковые, то сразу получишь результат - одинаковые куски или нет. Хотя при использовании справочников в этом случае необходимо не только код совать в документ, но и само значение справочника, если (как я правильно прочел выше) требуется такая точность. А вот уже если станет задача найти, где же различия, то придется и сам кусок разбирать, что уже не есть просто (хотя опять же нужно понимать степень требуемой детализации). Потому как если в старом отчете первой шла запись с ID = 15 (утрируем), а в свежем отчете первая запись идет с ID = 12 или 20, то нужно ли сканировать весь документ на предмет того, есть ли в нем все-таки запись с ID = 15 или нет? Если сканировать надо, то это уже получится совершенно нетривиальная задача (точнее сказать, очень ресурсоемкая). Хотя если найдено отличие, то в качестве аттрибута можно приделать флажок modified, и тогда с помощью xsl - схемы можно отчет получить очень красивый без всяких Crystal report. В общем, что там руками все делать, что там. Только вот T_SQL не очень то предназначен для таких вещей, IMHO. Стоит еще посмотреть возможность преобразования recordset <-> XML туда обратно через объект ADODB.Stream, который можно юзать с ADO 2.6 и выше. Там появляется возможность смотреть на рекордсет, вроде бы он как XML, а вроде как рекордсет. Если могу чем помочь по XML, то лучше в почту, потому как здесь я редкий гость. |
||
| 25.02.2002, 11:14 |
|
|
|
XML Reports
|
||
|---|---|---|
Участник
Сообщения: 9 135
|
||
|
Сравнивать два XML документа так же невозможно (в идеале), как и две таблицы.
Что ж, я рад, что мое мнение - не особенно расходилось с мнением профессионала... Поэтому, забыв на время об XML, хочу предложить следующую реляционную схему для решения проблемы: 1. Храним результаты вычислений всех отчетов в особой структуре, удобной для "сравнения" ("идентичные" версии хранить не обязательно); 2. Определяем максимально достоверную технику "сравнения" и согласовываем ее с заказчиком/боссом (любой здравомыслящий чел. - поймет, что идеальных решений не бывает); 3. Мысленно разбиваем любой отчет на 3 "источника и составные части": - наименование и/или ID отчета, как сущности, отличающее его от всех прочих "отчетов"; - "параметры отчета" (привязанные по FK к отчету); - "показатели отчета" (привязанные по FK к отчету); - "значения отчета" (привязанные по FK к отчету/параметрам/показателям); Т.к. большинство отчетов - суть таблицы, то упрощенно можно изобразить эту стуктуру так: Отчет_1 | Показатель_1 | Показатель_2 | ...... -----------+--------------------------------------- Параметр_1 | Значение_11 Значение_12 ...... Параметр_2 | ........... ........... ...... Параметр_3 | ........... ........... ...... Параметр_4 | ........... ........... ...... 4. Считаем отчеты "одинаковыми", если: а - у них одинаковые параметры; б - у них одинаковые показатели; в - у сочетаний параметр/показатель - одинаковые значения. (Сравнить 3 набора значений в 3-х таблицах - не столь уж сложная задача, ИМХО); 5. Договариваемся заранее - как будем "разводить" частные случаи: когда число параметров и/или показателей - заведомо переменное и зависит от текущего состояния базы? 6. Продумываем заранее - как будем обрабатывать "иерархические" параметры (типа - много-уровневой группировки с промежуточными суммами по группам)? Вперед, и с песней!!  |
||
| 26.02.2002, 07:50 |
|
|
