Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft Access Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 12   вперед  Ctrl      все
 интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Хотел бы поделиться с некоторыми своими наблюдениями, обнаруженными фактами. Хотелось бы осуществить что-то вроде «обмен мнений».
В и-нете много нестандартных решений казалось бы на первый взгляд «нереальных» задач. Когда начинаешь анализировать коды, то иной раз голова идёт кругом от длинного листинга, а чтобы разобраться иной раз необходимо потратить длительное время. Но разбираться в коде хочется.

Хочу начать с запросов.

Есть в этом форуме несколько интересных топиков о запросах. Вот некоторые из них:
- Самоправка запроса
- access сам меняет запрос
- Социологическое исследование: Как народ хранит запросы?
и т.д., и т.д.

Этот список можно продолжать достаточно долго.
А собственно, почему так происходит, почему Access самопроизвольно меняет SQL текстовку запроса?
На сей счёт у меня появилась версия-гипотеза. Я, конечно, не уверен в том, что мои догадки верны, хочу обсуждать с уважаемым гуру! Я считаю главной причиной «всех бед» это системная таблица «MSysQueries»! Кстати, есть интересная статейка, где как раз описываются некоторые детали данной таблицы: Как достать SQL запрос из *.mdb без MS Access
Чтобы правильнее объяснить то, что я имею ввиду, пожалуй, следует произвести следующий эксперимент:
Создаём простой запрос и назовем «Query1»
SELECT * FROM Table1;
Теперь создаём ещё один запрос «Query2», который будет ссылаться на наш 1-запрос.
SELECT * FROM Query1;

Далее, вручную поменяем название 1-запроса как «Q1».
С помощью VBA смотрим текст запроса «Query2».
Sub TestQuerySQL()
    Dim Qry As DAO.QueryDef
    Set Qry = CurrentDb.QueryDefs("Query2")
    Debug.Print Qry.SQL
    Set Qry = Nothing
End Sub

SQL текст запроса не изменился, хотя мы название 1-запроса поменяли.
А теперь откроем запрос «Query2» в режиме таблицы (можно вручную, а можно программно открывать, эффект – одинаковый). Access не будет ругаться, что не может найти «Query1». Ещё раз запустим процедуру TestQuerySQL.
Вуаля! В SQL тексте запроса «Query1» исчез, вместо него «Q1».
А как это произошло? Именно благодаря системной таблице «MSysQueries»! Помимо системных таблиц видимо Access где-то «запоминает» старое и новое название объекта после переименования. А перед открытием запроса, скорее всего перепроверяет не изменились ли названия объектов, которых использует данный запрос. Если да, то автоматически сам же подправляет. Вообщем-то всё это скорее сделано для «начинающих» пользователей, которые могут изменить названия объектов базы, но при этом могут и забыть подправить запросы.
Системная таблица «MSysQueries» разбивает запросы на поля и это означает, что не только название таблиц и запросов, используемые внутри определённого запроса, но и название полей имеет тот же эффект. Т.е. пусть «Таблица1» имеет поле «Поле1». Пишем такой простой запрос «Запрос1»:
SELECT Поле1 FROM Таблица1;
Теперь открываем «Таблица1» в режиме конструктора и поменяем название поля на «П1». После этого попробуем открыть «Запрос1» и как мы можем убедиться название поля в запросе автоматически поменялся на «П1», хотя мы запрос не корректировали.

Но не все запросы имеют такой эффект. А именно следующие виды запросов в системной таблице «MSysQueries» вообще не разбиваются на отдельные поля:
- запрос на объединение;
- запрос к серверу
- запрос на управление
- вложенный (внутренний) и подчинённый запрос.

«Запрос1» перепишем следующим образом:
SELECT *
FROM (SELECT П1 FROM Таблица1) AS Data;
Теперь открываем «Таблица1» в режиме конструктора и возвращаем предыдущее название поля «Поле1».
А вот теперь «Запрос1» у нас не будет работать правильно. Если откроете его, то Access воспримет «П1» как параметр, а не как название поля!

Видать не с проста Microsoft такие виды запросов как «Объединение», «К серверу», «Управление» отделил в своем интерфейсе отдельно как «Запрос SQL». Так как ими в основном пользуются не новички, а продвинутые пользователи, то и автоматическая корректировка посчитали излишней.
Итак, почему же Access самопроизвольно меняет SQL текстовку запроса? Потому что так Accessу более удобнее зафиксировать поля в системной таблице «MSysQueries». Здесь не хотелось бы использовать термин «оптимизатор запросов», ибо здесь не идёт в буквальном смысле оптимизация запросов, а скорее всего происходит «помощь чайникам». Может я сильно ошибаюсь по поводу полного отсутствия оптимизации, может и в правду хоть что-то Access наподобие SQL Server оптимизирует. Но очень часто после такой «оптимизации» сложные фильтры запроса получаются чересчур замудрёнными и порой некорректными. С одного раза даже и не понятно, что и как же запрос фильтрует.

Здесь также хочу отметить, почему же вложенных запросов Access 2003 и ранние версии отмечает внутри квадратных скобок. Дело в том, что когда Вы во внутри запроса соединяете более двух таблиц / запросов через INNER, LEFT, RIGHT JOIN, то отдельные части Access заключает в обычные скобки и всё, что находится во внутри этих обычных скобок Access разбивает и размещает у себя в таблице «MSysQueries». А вот когда Accessу как бы «нет необходимости» в разбивке (т.е. случай с вложенным запросом), то для «своего удобства» отмечает эту часть SQL текста особым образом. Ну и здесь есть косяк: так сказать «оптимизатор запросов» (который «оптимизирует» SQL текст запроса для размещения в таблице «MSysQueries») видимо сначала анализирует текст и отмечает ту часть, которую не надо разбивать, квадратными скобками. Ну а если уже в тексте есть оные, то тут разработчики видимо толком не объяснили «оптимизатору» как анализировать такие тексты. Т.к. «оптимизатор» не знает, что делать, то и предпочитает ругаться.
Но начиная с Access 2007 слегка такой «порядок вещей» был изменён разработчиками. Теперь «оптимизатор» не пишет квадратные скобки в SQL тексте, а держит «в уме» в момент фиксации SQL текста в системной таблице «MSysQueries». А когда кто-то изменит запрос, то и «оптимизатору» нечего ругаться, ибо в тексте изначально нет квадратных скобок.

P.S.
Надеюсь, народ начнёт критиковать мой топик и спорить. Как известно в спорах рождается истина.
4 фев 11, 15:23    [10184868]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Как оптимизировать запросы?

Как известно, существуют проверенные со временем старинные «лекарства», позволяющие повысить быстродействие запросов. Вот некоторые из них:
- по возможности вместо «HAVING» использовать «WHERE». Иногда требуется фильтровать данные после групповых функций таких как «MIN», «MAX», «AVG» и т.д. В таких случаях, увы фильтровать данные с помощью «WHERE» нельзя, придётся использовать «HAVING». А в остальных случаях нецелесообразно использование «HAVING».
- по возможности не использовать статистических функций по подмножеству, таких как Dsum, Dcount и т.д. В некоторых случаях если требуется обновляемость запроса, то приходится использовать подобные функции.
- по возможности не использовать подчинённые запросы на стороне «WHERE» или «HAVING». Иногда бизнес логика все же требует использование подчинённых запросов.
- если нет необходимости сортировки, то не применять ORDER BY.
Помимо этих способов Microsoft рекомендует:
- по чаще сжимать базу;
- использовать индексацию полей и т.д., и т.п.
Всем всё это известно. Ничего нового. А вот про IIF почти ни слова!
Что мы знаем про IIF? Если открыть справочник Access 2003, то там написано следующее:
Функция IIf всегда вычисляет и truepart, и falsepart, хотя возвращает только одно из них. Из-за этого могут возникнуть нежелательные побочные эффекты. Например, если в falsepart произошла ошибка при делении на ноль, эта ошибка возникнет, даже если выражение будет оценено как True.
Все эти слова оказались справедливы только для VBA, а вот для JET они не справедливы! Недавно Sator Arepo предоставил наиубедительнейший пример в другом топике.
select iif(true,'ok' ,1/0) as test
и
select iif(false,'ok' ,1/0) as test

Из этого следует одна очень полезная фитча:
Если в фильтре WHERE использованы несколько условий AND и OR, то вместо них можно использовать IIF и тогда запрос будет работать чуть быстрее.
Пример:
Вместо следующих условий
WHERE Field1 > 1 AND Field2 < 1000 AND Field3 BETWEEN 1 TO 100
Можно написать так
WHERE
IIf(Field1 <= 1, False,
IIf(Field2 >= 1000, False,
IIf(Field3 > 100, False
IIf(Field3 < 1, False, True))))
2-вариант с IIf работает быстрее, т.к. при первом же невыполнения условия «Field1 > 1» Access не станет проверять остальные условия и тем самым экономит время! Именно поэтому и в MS SQL Server ряд исследователей рекомендуют использование CASE WHEN … THEN … В Access аналог CASE WHEN это IIF.
При этом рекомендуется расположить условия наибольшего отбора выше по веткам IIF, тогда запрос станет наиболее оптимальным.
Условия отбора AND в IIF надо писать с точностью до наоборот, т.е. если Вам нужно условие Field1 > 1, то следует писать IIf(Field1 <= 1, False, а в самом конце True (как указано в примере). А вот условие OR придётся писать через = примерно так:
Допустим требуется фильтровать данные по следующим условиям:
WHERE Field1 = 1 OR Field2 = 2 OR Field3 = 3
Чтобы перевести на IIF следует писать так:
WHERE
IIf(Field1 = 1, True,
IIf(Field2 = 2, True,
IIf(Field3 = 3, True, False)))

Функция IIF имеет ещё одно преимущество:
Если использовать достаточно сложные условия отбора, то после сохранения запроса так сказать «оптимизатор» самопроизвольно «подтасует» условия так, как ему удобно (см. мой пост выше). А вот в случае IIF порядок проверки условий гарантированно не будет изменен «оптимизатором».
4 фев 11, 15:31    [10184926]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Иногда бывает полезным установить CHECK CONTRSTRAINT к определенной таблице, который может сверять данные одной таблицы с другой. Для этого вовсе не обязательно включать опцию "Синтаксис для SQL Server (ANSI 92)". Но в этом случае придётся установить его программно. Пример:
Допустим, у нас есть таблица "Контракт", где есть поле "КодКонтракта" и "Сумма", а также есть таблица "Спецификация", где есть поля: "КодКонтракта", "КодТовара", "Цена", "Количество". Если умножить "Цена" и "Количество" товара, то получим стоимость одной позиции товара. Предположим нам нужно установить ограничение: общая сумма всех позиций по одному контракту не должна превышать сумму контракта. Как это сделать?
Sub SetCheckConstraint()
    Dim strSQL AS String

    strSQL = "ALTER TABLE Контракт ADD CONSTRAINT СверкаСуммы CHECK " & _
        "((Контракт.Сумма >= (SELECT SUM(Цена*Количество) FROM Спецификация AS S " & _
        "WHERE S.КодКонтракта = Контракт.КодКонтракта)));"
    CurrentProject.Connection.Execute strSQL
End Sub

Ну и чтобы удалить ограничение нужно запустить такой код:
Sub DeleteConstraint()
    Dim strSQL AS String

    strSQL = "ALTER TABLE Контракт DROP CONSTRAINT СверкаСуммы"
    CurrentProject.Connection.Execute strSQL
End Sub

P.S. Ну а вообще конечно лучше использовать VBA функции, чтобы получить больше возможностей (Триггер Бенедикта). Я вышеуказанными примерами лишь подчеркнул, что включение опции "Синтаксис для SQL Server (ANSI 92)" вовсе не обязательное и как видите кириллица (по крайнем мере в А2003) проходит без проблем.
8 фев 11, 07:11    [10199883]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
alvk
Member [заблокирован]

Откуда: Находка
Сообщений: 10974
studieren,

А вот это уже интересно. Только насколько это оптимальнее чем другие способы (доп. поле в запросе(форме), рекордсет через подобную sql-строку, Dsum и т.д.)?
8 фев 11, 07:48    [10199904]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
alvk,

Вы на уровне базы устанавливаете ограничение. Кто-нибудь даже если создаст линкованную таблицу в "чужой базе" и попытается внести "неправильные" изменения, то уже не сможет.
Правда есть маленький нюанс: предметное "ругательство" (наподобие Validation Text) не возможно установить. Для этого ИМХО триггер Бенедикта лучче!
Кстати, удаление таблицы также невозможно до тех пор, пока существует CONSTRAINT.
8 фев 11, 08:05    [10199916]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
alvk
Member [заблокирован]

Откуда: Находка
Сообщений: 10974
studieren,

1. Тоесть сообщение выдать нельзя никакое? А разве здесь error не обрабатывается?(?)
2. Что касается удаления - пофиг, кто интересно свои рабочие таблицы с данными
удаляет? Только маньяк какой-нибудь..
8 фев 11, 09:12    [10200038]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Интересные факты.
Всем известно, что любой запрос в MS Access может иметь максимум 255 полей.
А вот в запросах на объединение (UNION) ограничение иное:
Общее количество полей каждого блока запроса в сумме не должно превышать 255!
Т.е. если 1-блок запроса содержит 128 полей и 2-блок запроса также имеет 128 полей, то Access будет ругаться, т.к. 128+128=256 (больше 255)!!!

Пример (этот запрос не пройдёт):
SELECT 1 AS F1, 2 AS F2, 3 AS F3, 4 AS F4, 5 AS F5, 6 AS F6, 7 AS F7, 8 AS F8, 9 AS F9, 10 AS F10,
11 AS F11, 12 AS F12, 13 AS F13, 14 AS F14, 15 AS F15, 16 AS F16, 17 AS F17, 18 AS F18, 19 AS F19, 20 AS F20,
21 AS F21, 22 AS F22, 23 AS F23, 24 AS F24, 25 AS F25, 26 AS F26, 27 AS F27, 28 AS F28, 29 AS F29,
30 AS F30, 31 AS F31, 32 AS F32, 33 AS F33, 34 AS F34, 35 AS F35, 36 AS F36, 37 AS F37, 38 AS F38, 39 AS F39,
40 AS F40, 41 AS F41, 42 AS F42, 43 AS F43, 44 AS F44, 45 AS F45, 46 AS F46, 47 AS F47, 48 AS F48, 49 AS F49,
50 AS F50, 51 AS F51, 52 AS F52, 53 AS F53, 54 AS F54, 55 AS F55, 56 AS F56, 57 AS F57, 58 AS F58, 59 AS F59,
60 AS F60, 61 AS F61, 62 AS F62, 63 AS F63, 64 AS F64, 65 AS F65, 66 AS F66, 67 AS F67, 68 AS F68, 69 AS F69,
70 AS F70, 71 AS F71, 72 AS F72, 73 AS F73, 74 AS F74, 75 AS F75, 76 AS F76, 77 AS F77, 78 AS F78, 79 AS F79,
80 AS F80, 81 AS F81, 82 AS F82, 83 AS F83, 84 AS F84, 85 AS F85, 86 AS F86, 87 AS F87, 88 AS F88, 89 AS F89,
90 AS F90, 91 AS F91, 92 AS F92, 93 AS F93, 94 AS F94, 95 AS F95, 96 AS F96, 97 AS F97, 98 AS F98, 99 AS F99, 100 AS F100,
101 AS F101, 102 AS F102, 103 AS F103, 104 AS F104, 105 AS F105, 106 AS F106, 107 AS F107, 108 AS F108, 109 AS F109,
110 AS F110, 111 AS F111, 112 AS F112, 113 AS F113, 114 AS F114, 115 AS F115, 116 AS F116, 117 AS F117, 118 AS F118, 119 AS F119,
120 AS F120, 121 AS F121, 122 AS F122, 123 AS F123, 124 AS F124, 125 AS F125, 126 AS F126, 127 AS F127, 128 AS F128
FROM MSysObjects;

UNION ALL SELECT 1 AS F1, 2 AS F2, 3 AS F3, 4 AS F4, 5 AS F5, 6 AS F6, 7 AS F7, 8 AS F8, 9 AS F9, 10 AS F10,
11 AS F11, 12 AS F12, 13 AS F13, 14 AS F14, 15 AS F15, 16 AS F16, 17 AS F17, 18 AS F18, 19 AS F19, 20 AS F20,
21 AS F21, 22 AS F22, 23 AS F23, 24 AS F24, 25 AS F25, 26 AS F26, 27 AS F27, 28 AS F28, 29 AS F29,
30 AS F30, 31 AS F31, 32 AS F32, 33 AS F33, 34 AS F34, 35 AS F35, 36 AS F36, 37 AS F37, 38 AS F38, 39 AS F39,
40 AS F40, 41 AS F41, 42 AS F42, 43 AS F43, 44 AS F44, 45 AS F45, 46 AS F46, 47 AS F47, 48 AS F48, 49 AS F49,
50 AS F50, 51 AS F51, 52 AS F52, 53 AS F53, 54 AS F54, 55 AS F55, 56 AS F56, 57 AS F57, 58 AS F58, 59 AS F59,
60 AS F60, 61 AS F61, 62 AS F62, 63 AS F63, 64 AS F64, 65 AS F65, 66 AS F66, 67 AS F67, 68 AS F68, 69 AS F69,
70 AS F70, 71 AS F71, 72 AS F72, 73 AS F73, 74 AS F74, 75 AS F75, 76 AS F76, 77 AS F77, 78 AS F78, 79 AS F79,
80 AS F80, 81 AS F81, 82 AS F82, 83 AS F83, 84 AS F84, 85 AS F85, 86 AS F86, 87 AS F87, 88 AS F88, 89 AS F89,
90 AS F90, 91 AS F91, 92 AS F92, 93 AS F93, 94 AS F94, 95 AS F95, 96 AS F96, 97 AS F97, 98 AS F98, 99 AS F99, 100 AS F100,
101 AS F101, 102 AS F102, 103 AS F103, 104 AS F104, 105 AS F105, 106 AS F106, 107 AS F107, 108 AS F108, 109 AS F109,
110 AS F110, 111 AS F111, 112 AS F112, 113 AS F113, 114 AS F114, 115 AS F115, 116 AS F116, 117 AS F117, 118 AS F118, 119 AS F119,
120 AS F120, 121 AS F121, 122 AS F122, 123 AS F123, 124 AS F124, 125 AS F125, 126 AS F126, 127 AS F127, 128 AS F128
FROM MSysObjects;
А вот если уберете 128-поле, то Access нормально воспримет запрос. Переключение на "Синтаксис для SQL Server (ANSI 92)" не спасёт, результат тот же.

Если в запросе на объединение имеется поле МЕМО, где имеется значение больше 255 символов, то Access вернет только первые 255 символов.
17 фев 11, 13:03    [10251063]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
Guest33
Member

Откуда:
Сообщений: 2071
автор
Если в запросе на объединение имеется поле МЕМО, где имеется значение больше 255 символов, то Access вернет только первые 255 символов.

Расшифруйте, пожалуйста. По моим наблюдениям, если в 1-й запрос включить мемо поле, то запрос с юнионом не режет длину строки.
17 фев 11, 13:58    [10251668]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
полином
Guest
studieren
Интересные факты.


о! сколько нам открытий чудных... (с)

studieren
Общее количество полей каждого блока запроса в сумме не должно превышать 255!


формулировочка
17 фев 11, 13:58    [10251674]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Guest33
автор
Если в запросе на объединение имеется поле МЕМО, где имеется значение больше 255 символов, то Access вернет только первые 255 символов.

Расшифруйте, пожалуйста. По моим наблюдениям, если в 1-й запрос включить мемо поле, то запрос с юнионом не режет длину строки.


Прошу прощения, что не уточнил деталь:
- если используете UNION ALL, то Access не режит.
- а вот если просто UNION, то Access покажет только первые 255 символов!

Вот теперь кажется описал полностью!

полином
studieren
Общее количество полей каждого блока запроса в сумме не должно превышать 255!


формулировочка


Ну хорошо, может быть написано не совсем правильно. Ну мысль я надеюсь Вы правильно поняли?
17 фев 11, 14:22    [10251856]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
полином
Guest
studieren
Ну мысль я надеюсь Вы правильно поняли?


не с первого раза :)
17 фев 11, 17:20    [10253227]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Вообще-то про особенность ограничения 255 полей в запросах на объединение решил здесь написать после того, как прочёл топик Too many fields defined.
В этом топике есть такой запрос:
SELECT Part_all, id, start_date, end_date, Description, Manager
FROM [
SELECT *,Part_M1 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M2 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M3 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M4 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M5 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M6 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M7 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M8 as Part_all FROM Main_Table 
UNION 
SELECT *,Part_M9 as Part_all FROM Main_Table 
UNION
SELECT *,Part_M10 as Part_all FROM Main_Table ]
WHERE (end_date>=Date()) and (Part_all<>'')
ORDER BY Part_all;

Автор также сообщает, что "в главной таблице 83 поля". Как мы видим в каждом блоке запросов есть дополнительное поле "Part_all", стало быть каждый блок имеет 84 поля. Всего блоков 10, в итоге мы имеем 84*10=840. А это гораздо больше чем 255!!!! Вот именно поэтому и Access ругается "Too many fields defined".

Вывод: в запросах на объединение нежелательно использовать "*", лучше явно указать только необходимые поля!

В том топике есть ссылка на интересный сайт, где имеется вот такая информация:
Tables: "Too many fields defined" error message
(Q) When I try to save a table, I keep getting the error message "Too many fields defined". What's causing this to come up?
(A) Access keeps an internal count of total number of fields in a table and has a limit of 255 fields per table. Each time you modify a field or add a field, this count increases by 1. When you delete a field, Access does NOT reset this counter. So it's possible for you to have less than 255 fields and still get this error message.
If your field count is less than 255, just compact the database again which should reset the internal field count counter.
17 фев 11, 19:45    [10253834]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
mds_world
Member

Откуда: Ташкент
Сообщений: 27576
studieren,

неплохо было бы вам проштудировать давний топик ФАК: А знаете ли вы, что... и то, чего там не хватает, добавить. В одном месте хранить все. Желательно было бы.
17 фев 11, 20:17    [10253911]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
8060
Guest
studieren, относительно количества полей в UNION можно посмотреть в этом и следующем за ним постах.
17 фев 11, 20:36    [10253973]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
mds_world,

Не знал, что есть топик "А знаете ли Вы ..." :))

И что в результате? Опять закроют мой топик? Если это так, то жаль! :((
17 фев 11, 20:41    [10253991]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
8060
studieren, относительно количества полей в UNION можно посмотреть в этом и следующем за ним постах.


Спасибо за ссылку!
Значит я ошибся. Бывает.
17 фев 11, 20:45    [10254000]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
mds_world
Member

Откуда: Ташкент
Сообщений: 27576
studieren
mds_world,

Не знал, что есть топик "А знаете ли Вы ..." :))

И что в результате? Опять закроют мой топик? Если это так, то жаль! :((

Вовсе нет! Я, во всяком случае этого делать не собираюсь.

Вопрос ведь иначе ставится - в аксе есть много различных особенностей, подмеченных разными авторами. Желающему программировать в этой среде полезно их знать. Но поиск затруднителен. Хотя бы потому, что не знаешь, что искать. А когда все собрано в одном месте удобно.
17 фев 11, 20:54    [10254020]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
alvk
Member [заблокирован]

Откуда: Находка
Сообщений: 10974
mds_world,

Есть "золотые топики". Они одни, слово "золотые" встречается крайне редко на форуме.
18 фев 11, 02:46    [10254783]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
А2003

Странную вещЧ я сейчас обнаружил.
Допустим есть такой запрос
SELECT * FROM Table1

Можно его переписать вот так
TABLE Table1
После сохранения запроса текст вернётся к 1-варианту. Об этом написано в "ФАК: А знаете ли вы, что... ". Все нормально, всё О.К. Но обнаружил и такую странность. Можно этот же запрос переписать вот так:
SELECT *
FROM [TABLE Table1]. AS X;
Обратите внимание: здесь использована квадратная скобка [ ].. Запрос можно сохранить и Access не ругается. А вот если заменить квадратную скобку на обычную скобку, тут уж Access начинает кричать!!! Все время боролся с квадратными скобками во вложенных запросах, а теперь на тебе Access требует их!!!

Продолжил эксперимент и написал вот такой запрос:
SELECT *
FROM [PARAMETERS x Long;
SELECT * FROM MSysObjects AS O WHERE Id = x]. AS Data;

Обычно Access не терпит PARAMETERS во вложенных запросах. А здесь парадокс - пашет как надо! И здесь квадратные скобки никак нельзя заменить на обычные скобки!

P.S. Смотрю на всё это и диву дивлюсь: сколько же ещё секреты спрятаны за семью замками.
18 фев 11, 11:06    [10255703]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Просьба тем, у кого есть А2007 или А2010: не могли бы протестировать вот эти запросы? К сожалению у меня в наличии нет таких версий под рукой.
TABLE Table1
SELECT *
FROM [TABLE Table1]. AS X;
SELECT *
FROM [PARAMETERS x Long;
SELECT * FROM MSysObjects AS O WHERE Id = x]. AS Data;
18 фев 11, 11:19    [10255803]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
П-Л
Guest
Уже достаточно причин для ухода с MDB в ADP
18 фев 11, 11:23    [10255844]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
8060
Guest
studieren
Странную вещЧ я сейчас обнаружил.

Вот здесь пример "странного" запроса без всяких наворотов (в двух постах ниже эта "странность" обсуждается).
18 фев 11, 11:32    [10255917]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
alvk
Member [заблокирован]

Откуда: Находка
Сообщений: 10974
П-Л
Уже достаточно причин для ухода с MDB в ADP


У меня пока нет ни одной, кроме личного интереса. А будущий переход на акс2010 разве это позволит сделать?

p.s. извиняюсь за оффтопик.
18 фев 11, 12:13    [10256345]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
studieren
Member

Откуда: Tashkent, Uzbekistan
Сообщений: 2845
Если в А2007 написать вот такой запрос в режиме SQL и затем открыть его в режиме таблицы, то запрос работает:
SELECT *
FROM [PARAMETERS x Long;
SELECT * FROM MSysObjects AS O WHERE Id = x]. AS Data;

Но!!! Если сохранить запрос, то Access текст SQL меняет до неузнаваемости!
SELECT *
FROM (PARAMETERS x Long)  AS Data;
И естественно НЕ РАБОТАЕТ после этого запрос!
Да!!! Дела!!!
В А2010 не смог экспериментировать из-за не имения, но подозреваю, что там дела обстоят аналогично.

Попробовал экспериментировать с перекрестным запросом в А2007:
SELECT *
FROM [TRANSFORM SUM(S.Quantity) AS Total
SELECT S.SaleDate
FROM tblSale AS S INNER JOIN tblProduct AS P ON S.ProductID=P.ProductID
WHERE S.SaleDate>=#1/1/2011#
GROUP BY S.SaleDate
PIVOT P.Product IN ('Товар№1', 'Товар№2', 'Товар№3')].  AS Sale;
Вот так в А2007 можно сохранить запрос. Все работает вроде нормально. Но!!! Теперь А2007 после сохранения запроса меняет автоматически квадратные скобки на обычные. А вот если попробовать что-то изменить, теперь ругается. Нужно каждый раз вернуть квадратные скобки вместо обычных. Т.е. всё происходит с точностью до наоборот.
21 фев 11, 09:46    [10265133]     Ответить | Цитировать Сообщить модератору
 Re: интересные факты / наблюдения / анализ чужих и собственных решений  [new]
mds_world
Member

Откуда: Ташкент
Сообщений: 27576
studieren,

посмотрите: Самоправка запроса

Сообщение было отредактировано: 21 фев 11, 09:56
21 фев 11, 09:56    [10265204]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 12   вперед  Ctrl      все
Все форумы / Microsoft Access Ответить