Akina

Знак присвоения без SET присваивает скалярное значение. А с SET - ссылку на объект. То есть использовать его или нет - зависит от типа значения справа от знака присвоения. Ну и желаемого результата, конечно (включая и желание не получить ошибку несоответствия типов).

Пример.

• Откройте Excel.
  
• Откройте окно редактора VBA (Ctrl-F11). Измените размеры окон так, чтобы видеть и таблицу, и редактор.
  
• В редакторе добавьте модуль (Insert-Module).
  
• Вставьте в модуль следующий текст:
  

  Sub test()
  Dim x, y
  Range("A1").Value = 123
  x = Range("A1")
  Set y = Range("A1")
  End Sub

  
  
• Поставьте курсор в середину модуля, и начните пошаговое выполнение нажатием F8. Доведите исполнение до финального End Sub (когда эта строка будет подсвечена жёлтым цветом).
  
• Откройте окно локальных переменных (View - Locals Window).
  

Вы увидите, что первый оператор присвоения присвоил переменной x скалярное значение. Поскольку справа был объект, то в качестве скалярного значения было взято свойство объекта по умолчанию. Для объекта типа Range объектом по умолчанию является его свойство .Value - посему в переменную помещено значение 123. И соответственно переменная имеет тип Variant/Double.

А вот второй оператор присвоения, использующий Set, поместил во вторую переменную y ссылку на объект Range. И переменная имеет тип Variant/Object/Range.

WITH cte AS (
    SELECT a, b, c, COUNT(*) OVER (PARTITION BY a, c) cnt
    FROM table
)
SELECT a, b, c
FROM cte 
WHERE cnt > 1

не пойму что ей надо

Надо, чтобы в поле cat_id таблицы post уже присутствовало значение, которое ты присваиваешь полю id во вставляемой записи.

Оптоволокно обеспечивает магистральную передачу.
Соответственно оптика разваривается на панель в кроссовой и оптическим патч-кордом подключается к транковому оптическому порту магистрального коммутатора (скорее всего L2+), в который вставлен оптический модуль. На обеих сторонах.

Применительно к данной конкретной задаче:

• СУБД предназначена для хранения и обработки массивов данных.
  
• ЯП предназначен для обеспечения пользовательского интерфейса этого процесса и управления им.
  

По-моему, выбор стороны для проведения обработки очевиден.

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

Внешний ключ (FOREIGN KEY) - это ПРАВИЛО. Всё остальное - либо дополнения, либо следствия. Народ начинает рассказывать про индексы и прочее - НЕТ! Не включайте всё это в определение собственно внешнего ключа.

Хотя оно хранится в структуре таблицы, оно является не частью структуры таблицы, а инструкцией, которая будет обрабатываться подсистемой контроля целостности и непротиворечивости данных - есть такая в составе SQL-сервера.

Это правило устанавливает, что при добавлении/изменении значения следует проверить существование нового значения в ссылочной таблице. И наоборот - при удалении следует проверить отсутствие удаляемого значения в ссылающейся таблице. То есть правило работает в обе стороны - влияет не только на таблицу, в которой оно определено, но и на упомянутую в правиле таблицу, при этом в структуре ссылочной таблицы никакого упоминания о существовании этого правила нет. Но, поскольку подсистема контроля - это подсистема уровня сервера, то ей плевать, где прописано.

Это правило может быть дополнено опциями каскадной операции ON DELETE/UPDATE - в этом случае после контроля нового значения подсистема даёт дополнительную команду на выполнение указанных в опции изменений зависящих данных.

Впрочем, создание внешнего ключа может и приводить к изменению структуры. Но не той таблицы, в которой создаётся внешний ключ, а в той, на которую этот ключ ссылается. дело в том, что для эффективной работы подсистемы контроля в ссылающейся таблице должен существовать индекс, который может и будет использоваться для эффективного контроля. То есть либо выражение внешнего ключа должно совпадать с выражением индекса, либо быть его префиксом. Некоторые СУБД при отсутствии такого индекса создают его автоматически, некоторые завершают попытку создания с ошибкой.

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

create table test(
  id SERIAL PRIMARY KEY,
  num int,
  t text,
  constraint u_constrainte unique (num, t) DEFERRABLE 
)

https://dbfiddle.uk/VuwdSZSH

Можно ли как то сделать сортировку того что нужно обновить перед тем как собственно обновлять записи?

Нет.

Для поиска двойной кавычки используется строковый литерал из четырёх двойных кавычек
Instr(start, variable, """")
Первая и последняя обрамляют литерал, вторая и третья образуют удвоенную двойную кавычку, которая интерпретируется как квотированная/экранированная.

Есть и более простой способ.
Instr(start, variable, Chr(34))

-=о=--=о=--=о=--=о=--=о=--=о=--=о=-

У меня в ячейки есть текст:
ДООП "Лабаратория Хлеба" естественно-научной направленности

Надо что бы она в соседнюю ячейку написал:
ДООП "Лабаратория Хлеба"

Если ты точно знаешь, что значение содержит не менее 2 двойных кавычек, и нужно отделить именно до второй включительно, можно так:

Function get2dquotes(source As String) As String
    Dim tmp() As String
    tmp = Split(source, Chr(34))
    get2dquotes = tmp(0) & Chr(34) & tmp(1) & Chr(34)
End Function

И соответственно потом B1=get2dquotes(A1).

Глобально: никакие.

Уровня БД либо отдельных объектов БД: данные - всё, кроме FILE; структура - CREATE TEMPORARY TABLES и (если используются хранимые объекты) EXECUTE.

Ну а далее - плюс дополнительные необходимые права, в зависимости от кривизны структуры и работы с базой.