Ситуация: Запрос на создание таблицы в режиме таблицы выдаёт 4019 записей. А если выполнить этот запрос, то в полученой таблице лишь 3952 записей.
Вопрос: отчего так может случаться и как с этим бороться
Спасибо.

З.Ы.: а чего забросили мой предыдущий топик? или на те вопросы невозможно ответить (или можно, но не вежливо)

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

http://www.financegroup.kiev.ua/temp/db1.rar

Там правда немного другое кол-во записей, нежели я описывал (4021 в запросе Объединение абсолютное и в запросе agg1 , если его открыть в режиме формы). Однако, если его выполнить, то в результирующей таблице test_agg - 3954 записей.

CtrlAlt, повторяющиеся записи правда могут быть. Однако разве один и тот же запрос не должен в режиме формы и при создании таблицы выдать одно и то же кол-во записей? Или я ошибаюсь?

А что конкретней с ключевыми полями в таблице?

Спасибо.

CtrlAltПосмотри ключевые поля в таблице. И нет ли дублирующихся строк в запросе

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

Mufta_VladМогу предположить, что в таблице с которой берутся записи для добавления, присутствуют пустые поля. В данной ситуации запрос на добавление игнорирует их, отсюда и разница в источнике и в получателе. Т.е. в получатель не добавляются данные, где были пустые поля.
Боюсь, что это не так. Записей, где все 4 поля (по которым происходит выборка) пустые - нет. А поочерёдно пустые поля запрос отобрал нормально - все они попали в запрос.
Проблема в другом - запрос на добавление добавляет не все записи из тех, которые показывает сам же в режиме таблицы.

Спасибо.

Уважаемые Geo и ЛП, конечно, можно! Я даже с этой целью и ссылочку поместил чуть выше (6-ю сообщениями выше). Ну ежели не хотите качать 500 кил. Разражусь тут:

SELECT [Объединение абсолютное].Модель, [Объединение абсолютное].Подкатегория, [Объединение абсолютное].ManID, [Объединение абсолютное].Описание INTO test_agg
FROM [Объединение абсолютное];

Однако лучше вам таки глянуть на всю систему запросов.

Rivkin DmitryUNION ALL
понял, спасибо.

Лох Позорныйкачать я вообще ничего не буду (религия не позволяет)
а вот насчет того как ты этот запрос запускаешь - еще раз спрошу.
Хорошо. Различия в кол-ве записей у меня появляются когда я:

1) открываю этот запрос в конструкторе, а затем - в режиме таблицы. Кол-во записей: 4021
2) запускаю даный запрос и он кричит, что добавил в таблицу 3954 записи

Хочу однако добавить, что если убрать дубли в исходном запросе всё будет чики-пики. Но из принципа хочу понять, почему при дублях есть это несоответствие.

GeoВ вашей ссылочке полмегабайта весу. Оно мне надо? Эх... Ладно...
Во как...

Причем это не в группировке дело - группировка по созданной test_agg дает еще меньше записей.

Нашшупал:

SELECT distinctrow NProduct.Модель, NProduct.Подкатегория, NProduct.ManID, NProduct.Цена, NProduct.Описание, Product.CategoryID
FROM NProduct INNER JOIN Product ON (NProduct.Подкатегория=Product.CategoryID) AND (NProduct.Модель=Product.ProductShortDescriptionRUS) AND (NProduct.Описание=Product.ProductLongDescriptionRUS) AND (NProduct.ManID=Product.ManufacturerID);

Если его убрать, получится три восемьсот с чем-то записей. И столько же создастся. Глюк-с? Не знаю. А зачем тут distinctrow?

Пардон за огромный файл, но порезав исходные таблицы, глюк исчезает. Потому пришлось постить as is.

Думаю, Вы правы. Уберу distinctrow, лучше почищу исходные таблицы от полных дублей. А в запрос вставлю distinct или вообще ничего - так, вроде, не глючит.

А вы вообще с таким сталкивались?

Спасибо.

GeoВ вашей ссылочке полмегабайта весу. Оно мне надо? Эх... Ладно...
Во как...

Причем это не в группировке дело - группировка по созданной test_agg дает еще меньше записей.

Нашшупал:

SELECT distinctrow NProduct.Модель, NProduct.Подкатегория, NProduct.ManID, NProduct.Цена, NProduct.Описание, Product.CategoryID
FROM NProduct INNER JOIN Product ON (NProduct.Подкатегория=Product.CategoryID) AND (NProduct.Модель=Product.ProductShortDescriptionRUS) AND (NProduct.Описание=Product.ProductLongDescriptionRUS) AND (NProduct.ManID=Product.ManufacturerID);

Если его убрать, получится три восемьсот с чем-то записей. И столько же создастся. Глюк-с? Не знаю. А зачем тут distinctrow?

Пардон за огромный файл, но порезав исходные таблицы, глюк исчезает. Потому пришлось постить as is.

Думаю, Вы правы. Уберу distinctrow, лучше почищу исходные таблицы от полных дублей. А в запрос вставлю distinct или вообще ничего - так, вроде, не глючит.

А вы вообще с таким сталкивались?

Спасибо.

краснобай и баламут3898<>3954

Удивительное рядом (но оно запрещено):
если убрать DISTINCTROW , то это равносильно замене его на ALL.
Вопрос на засыпку: почему SELECT ALL возвращает меньше записей(3898), чем SELECT DISTINCTROW (4021)??

ничего не понимаю (с)

вот и я о том же

GeoМ.б. база покоцанная?..
такое можно допустить,
за целесность базы отвечать не могу - машина висла пару раз
хотя работаю с ней только я

ладно, попробую начать с нуля - заново создам таблицы (я их из Excel импортирую). интересно, а запросы надо переписывать.

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

всем спасибо

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

однако, я нашёл рациональное зерно в том, что Вы рекомендуете.

в одну и ту же таблицу я поместил результаты выполнения Объединение абсолютное и запроса противоположного даному. в результате, по закону сохранения материи должны были получится те же записи, что есть в исходной таблице. Однако этого не вышло. Точнее, вышло, но не совсем. Их было меньше на около 60.

Выбрав те, которых нехватало, в отдельную таблицу, я таки прошёлся по ним глазами и посмотрел, где может падать проверка .
Оказалось, что часть из них имеет в одном и том же поле (текстовом) нестандартные символы: ®, °, • и некоторые другие.
Заменив их на *, кол-во исчезнувших записей уменьшилось до 35
Стало быть собака частично порылась именно тут.
Вопрос: У Accessa что есть какие-то символы из юникода, с которыми он не работает? В таком случае, так бы и сказал, а то показывает, поиском ищет, а в запросах - чудеса. Или я чего-то не понял?
Дальше, я обратил внимание, что оставшиеся "выпавшие" записи всё в том же поле имеею большой размер: от 202 до 255. При этом ограничение размера поля стоит 255. Я попробовал уменьшить макс. размер до 250 (конечно, мне записи в этом поле обрезало) и вуаля - проблемный записей стало ещё на 10 меньше... Дальше продолжать эксперимент не могу, надо сохранить длину поля хотя бы такой.
Вопрос: А что у Accessa есть какое-то ограничение по длине поля, о котором я не знаю? Проблема опять таки видна только через запрос: все длинные записи видно и они нормально ищутся поиском... Что делать?