Доступ к усечению поля Query Memo из-за «отличного»

Question

У меня проблемы с запуском запроса без усечения поля заметки в NotesTbl или возврата повторяющихся записей.

UID не уникален для AccessTbl. Когда я пропускаю «отдельные» заметки, они будут возвращаться несколько раз, потому что я присоединяюсь к AccessTbl при нечетком условии. Когда я использую distict, поле примечания обрезается, потому что это поле memo.

Вот мой запрос:

SELECT DISTINCT NotesTbl.pin, NotesTbl.noteid, NotesTbl.note, NotesTbl.date,
AccessTbl.affiliation, AccessTbl.name
FROM NotesTbl
LEFT JOIN AccessTbl
ON NotesTbl.UID = AccessTbl.UID
WHERE PIN = #pin#
AND UID = '#uid#'
ORDER BY NotesTbl.DATE DESC

Answer 1

Я нашел решение, которое, кажется, работает. Я использовал «group by», чтобы установить отличимость PIN-кода и NoteID. Я попытался исключить примечание из сравнения отличия, используя First (), чтобы избежать усечения.

SELECT NotesTbl.pin, NotesTbl.noteid, First(NotesTbl.note) as notebody, NotesTbl.date,
AccessTbl.affiliation, AccessTbl.name
FROM NotesTbl
LEFT JOIN AccessTbl
ON NotesTbl.UID = AccessTbl.UID
WHERE PIN = #pin#
AND UID = '#uid#'
GROUP BY pin,affiliation,name,date,noteid
ORDER BY NotesTbl.DATE DESC

Answer 2

Механизм базы данных Access обычно определяет уникальность текстовых ('String') данных, используя только первые 255 символов, поэтому DISTINCT и GROUP BY будут усекаться.

Это предложение немного затянуто, но оно работает: разбейте MEMO на куски по 255 символов, используйте DISTINCT на кусках, а затем соедините их снова вместе, например, (Доступ к синтаксису режима запросов ANSI-92 ядра базы данных, то есть к подзапросам):

SELECT DT2.MyMemoCol_1 & DT2.MyMemoCol_2 AS MyMemoCol
  FROM (
        SELECT DISTINCT DT1.MyMemoCol_1, DT1.MyMemoCol_2
        FROM (
              SELECT MID(MyMemoCol, 1, 255) AS MyMemoCol_1, 
                     MID(MyMemoCol, 256, 255) AS MyMemoCol_2 
                FROM Test1
             ) AS DT1
       ) AS DT2;

---

Комментарий опубликован:

Разбивка памятки на 255-символьные куски полностью ненужным. Вы можете просто отсортировать Слева (MyMemoCol, 8192) или какой-то другой соответственно выбранное значение для длина поля возвращается.

Ну, в моем тестировании это вообще не работает. Быстрое воспроизведение:

CREATE TABLE Test1 (MyMemoCol MEMO NOT NULL);

INSERT INTO Test1 (MyMemoCol) VALUES (STRING(300, 'A'));
INSERT INTO Test1 (MyMemoCol) VALUES (STRING(300, 'A') & STRING(5, 'X'));
INSERT INTO Test1 (MyMemoCol) VALUES (STRING(300, 'A'));

SELECT LEFT$(MyMemoCol, 8192)
  FROM Test1
 GROUP 
    BY LEFT$(MyMemoCol, 8192);

Протестировано с использованием представления SQL объекта ACE механизма доступа Access2007 .accdb в режиме запросов SQL-92. Запрос возвращает одну строку (неверно), значение которой было усечено до 255 символов (неверно).

Предыдущий запрос "chunking" возвращает две строки (правильно) без усечения (правильно).

Answer 3

Вы также можете отфильтровать объект запроса на конце CF, чтобы удалить (или проигнорировать) ответы, которые уже были отображены. Неэффективно, но если вы используете Acess, я предполагаю, что интенсивный трафик не является большой проблемой.

Что-то вроде:

<cfoutput query="notes">
   <cfset diplay="true">
   <cfloop from="1" to="#notes.currentrow-1#">
       <cfif note neq notes.note[i]>
            <cfset display="false">
       </cfif>
    </cfloop>
    <cfif display>
       #note#
    </cfif>
</cfoutput>

Для большого количества возвратов n это будет некрасиво в O (n ^ 2), но для маленьких n оно должно дать вам то, что вы хотите.

Answer 4

Редактировать: - Удалено первое предложение -

... Другим методом будет разбить ваш запрос на два запроса: один, который уточняет AccessTbl, чтобы UID был уникальным в запросе, и другой, который присоединяет NotesTbl к только что созданному запросу qryAccessTblUnique.