Откуда берётся тип данных varchar, если связь идёт от PK?

Question

Откуда берётся тип данных varchar, если связь идёт от PK?

Курай Знаток (380), на голосовании 3 месяца назад

Переношу бд из access в SSMS. В собирательной таблице "Обращения" в access'е стоит тип данных "Числовой", но в ssms ни с float, ни с int/decimal сохранить не получается.

Мне нужно, чтобы при запросе к vizitz мне показывались все данные, относящиеся к указанному id. В чём моя ошибка и как её исправить

Answer 1

Данечка Волков Мыслитель (8038) 4 месяца назад

Тип данных VARCHAR в MySQL хранит строку переменной длины (от 0 до 2 16-1 символов), которая также задается на этапе создания таблицы. В отличие от CHAR он хранит только указанную длину, а также выделяет 1 байт для хранения длины строки

КурайЗнаток (380) 4 месяца назад

мне эта информация известна. если не знаете ответа на вопрос, то попрошу не беспокоить

Данечка Волков Мыслитель (8038) Курай, 6.2.3.1 Типы данных CHAR и VARCHAR Типы данных CHAR и VARCHAR очень схожи между собой, но различаются по способам их хранения и извлечения. В столбце типа CHAR длина поля постоянна и задается при создании таблицы. Эта длина может принимать любое значение между 1 и 255 (что же касается версии MySQL 3.23, то в ней длина столбца CHAR может быть от 0 до 255). Величины типа CHAR при хранении дополняются справа пробелами до заданной длины. Эти концевые пробелы удаляются при извлечении хранимых величин.

Answer 2

Основываясь на вашем описании и изображении, вот несколько ключевых моментов:

Тип данных varchar не должен появляться для первичных ключей (PK). Обычно PK имеют числовой тип данных, такой как int или bigint.
Проблема с переносом из Access в SSMS может быть связана с несоответствием типов данных. В Access "Числовой" тип может соответствовать разным типам в SQL Server, в зависимости от настроек поля.
Для решения проблемы:

Проверьте точные настройки "Числового" поля в Access (размер поля, формат и т.д.).
В SSMS попробуйте использовать более общий тип, например bigint, если это целые числа, или numeric/decimal с достаточной точностью, если есть дробная часть.
Убедитесь, что данные в Access не содержат нечисловых значений или null, которые могут вызывать ошибки при импорте.

Для корректной работы запросов к vizitz:

Убедитесь, что типы данных ключевых полей в связанных таблицах совпадают.
Проверьте правильность определения связей между таблицами.

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

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

Answer 3

Ошибку нужно полностью показывать, на скрине написано что не может строку записать в целочисленное поле ( а почему по скрину не определить )

Answer 4

очень похоже на то что в исходной базе какой-то бардак устроили... バカにつける薬はない。。。