Если установить через setData(..) значение поля таблицы, а потом сразу прочитать его через data(..), то результат очевидно будет такой же не зависимо от стратегии модели данных.
Потому, что setData и data работают с единым хранилищем данных в конкретной стратегии редактирования модели данных.
База данных это по сути данные в файловой системе.
OnFieldChanged стратегия сразу вызывает запись в базу при установке нового значения полю таблицы. И сразу потом идет select к базе данных и таблица обновляется.
Буквально сразу вызывается query update запрос.
Стратегия модели данных onRowChanged подразумевает, что изменения накапливаются в буфере editBuffer и запись в базу данных кэша будет происходить не просто при потере фокуса строки (переход на другую строку), а при записи в поле другой уже строки.
До этого момента при setData данные будут меняться только в буфере редактируемой строки, а именно в editBuffer.
Стратегия onManualSubmit ничего не записывает в базу пока вы не вызовете вручную submitAll, до этого момента все изменения накапливаются в кеше, смотрите контейнер cache.
Все вроде понятно, но когда, где и какую стратегию надо использовать.
Можно привести очень характерный пример таблицы представленной классами: модели данных my_QSqlTabelModel, унаследованной от QSqlTabelModel, и визуального ее представления my_QTableView, унаследованной от QTableView.
В таблице допустим есть вычисляемое поле sum, которое зависит от значений полей price и qty. То есть sum должно устанавливаться автоматически при установке price или qty (sum=price*qty).
И еще есть много полей, корректность значений которых (корректность сочетаний и т.д.) надо проверять перед записью в базы.
Так как после записи в базу уже проверять что-то поздно, то логично надо все проверять до записи в базу данных.
Причём при полученных не корректных сочетаний значений полей мы должны аннулировать попытку установки значения поля в базе данных и визуально в таблице тоже отменить.
Это касается не только редактирования поля, но и копирования строки.
Может показаться, что если строка источник копирования корректная, то как может быть некорректной ее копия. Но так тоже бывает в разных алгоритмах проверки корректности всей таблицы. Например итог по колонке sum не может превышать определенный лимит.
Надо учесть, что аналогичная ситуация бывает и при удалении строки.
Так вот напрашивается такая логика использования стратегий.
Использование onFieldChanged надо запрещать, так как идет сразу запись в базу.
Далее по умолчанию для таблицы устанавливаем стратегию onRowChanged.
В модели данных my_QSqlTabelModel реализуем вычисление sum, то есть делаем setData для sum, если делается setData для price или qty.
Но только при стратегии onRowChanged. Это важно!
Вызывает нашу функцию с алгоритмом проверки разных корректностей (назовём ее sig_recalculation). sig потому что удобнее ее реализовать как сигнал.
Если sig_recalculation возвращает true (а сигналы могут возвращать значения), то вызываем submit, иначе revert в модели данных.
Теперь по поводу проверки корректности данных таблицы при копировании строки или удалении.
Может показаться, что временно можно установить стратегию в один вариант, например onManualSubmit, а впоследствии вернуть обратно, но на самом деле надо просто хорошо разобратся и понять разные стратегии и менять их динамически не надо. Это только больше запутает.