SQL Server повідомляє "Недійсне ім'я стовпця", але стовпець присутній і запит працює через студію управління

107

Я трохи вдарив у глухий кут. У мене є запит, який генерується деяким C#кодом. Запит працює нормально, Microsoft SQL Server Management Studioколи працює проти однієї бази даних.

Однак коли мій код намагається запустити той самий запит, я отримую ту ж помилку щодо недійсного стовпця, і викид викидається. Усі запити, на які посилається цей стовпець, не вдається.

Стовпець, про яку йдеться, нещодавно було додано до бази даних. Це стовпчик дати Incident_Begin_Time_ts.

Приклад цього не вдається:

select * from PerfDiag 
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';

Інші запити, як-от Select MAX(Incident_Being_Time_ts);також, не спрацьовують при запуску коду, оскільки він вважає, що стовпець відсутній.

Якісь ідеї?

sql sql-server

— kidl33t
джерело

Можливо, це проблема зі справою? Можливо, Management Studio не хвилює справи, тоді як інші способи доступу до бази даних є більш суворими.

— Олівер

1

Ви впевнені, що маєте ту саму базу даних у своєму коді, що і та, що знаходиться в студії управління?

— rlb.usa

3

Ви впевнені, що ім'я стовпця, створене в C #, та ім'я стовпця, яке ви намагаєтеся запитувати, точно збігаються? У своєму запитанні ви двічі пишете "Інцидент _ Початок _ Час_ц" і один раз "Інцидент _ Будучи _ Час_тс".

— Крістіан Шпехт

1

@Oliver: Чутливість до регістру не пов'язана з підключенням. Це як варіант сервера бази даних / sql.

— Ніколас Кері

65

Я підозрюю, що у вас є дві таблиці з такою ж назвою. Одному належить схема 'dbo' ( dbo.PerfDiag), а інша належить схемі за замовчуванням облікового запису, що використовується для підключення до SQL Server (щось подібне userid.PerfDiag).

Якщо у вас є некваліфіковане посилання на об’єкт схеми (наприклад, таблицю) - не кваліфіковану за назвою схеми - посилання на об'єкт має бути вирішено. Розв’язання імені відбувається шляхом пошуку в наступній послідовності об'єкта відповідного типу (таблиці) із заданим іменем. Назва відповідає першому збігу:

За схемою за замовчуванням користувача.
За схемою 'dbo'.

Некваліфіковане посилання пов'язане з першим збігом у вищезазначеній послідовності.

Як загальна рекомендована практика, завжди слід кваліфікувати посилання на об'єкти схеми з міркувань продуктивності:

Некваліфіковане посилання може визнати недійсним кешований план виконання для збереженої процедури або запиту, оскільки схема, до якої посилалася прив'язка, може змінюватися залежно від облікових даних, що виконують збережену процедуру або запит. Це призводить до перекомпіляції запиту / збереженої процедури, до результатів. Рекомпіляції спричиняють зняття блоків компіляції, перешкоджаючи доступу інших до необхідних ресурсів.
Роздільна здатність імені сповільнює виконання запитів, оскільки для вирішення імовірної версії об'єкта (що належить 'dbo') необхідно зробити два зонди. Це звичайний випадок. Єдиний раз, коли один зонд вирішить ім'я, це якщо поточний користувач володіє об'єктом вказаного імені та типу.

[Відредаговано для подальшої примітки]

Інші можливості (не в певному порядку):

Ви не підключені до бази даних, яку ви вважаєте.
Ви не підключені до екземпляра SQL Server, про який ви думаєте.

Двічі перевірте рядки підключення та переконайтеся, що вони чітко вказують ім'я екземпляра SQL Server та ім'я бази даних.

— Ніколас Кері
джерело

4

+1 Я використовую sql-профілер для відстеження таких проблем. Кожен раз, коли ви маєте справу з динамічним sql з інших програм, захопіть запит із слідом, скопіюйте та вставте його у нове вікно запиту, натисніть кнопку "Виконати", щоб дізнатися, що не так. Це також підтвердить, що ви підключаєтесь до правильного екземпляра та db, як було запропоновано вище.

— Брайан

2

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

— Nick.McDermaid

Спершу спробуйте Ctrl + Shift + R, щоб перезавантажити кеш. Найгірше, що ви витрачаєте лише кілька секунд.

— radbyx

267

Просто натисніть Ctrl+ Shift+ Rі подивіться ...

У студії управління SQL Server Ctrl + Shift + R оновлює локальний кеш.

— Мангеш
джерело

Чому ви вважаєте, що це може бути корисним?

— дружня

7

У студії управління SQL Server Ctrl + Shift + R оновлює кеш Intellisense. Це не дозволило Управлінській студії скаржитися, що додані мною стовпці є недійсними, але я думаю, що це була оселедець (я все ще маю проблему, як оригінальний плакат, під час доступу до цих нових стовпців з коду).

— Джайлс

2

Здається, щоразу, коли я додаю міграцію, а потім оновлюю базу даних, я повинен це зробити. Інакше я розумію, що це недійсне ім’я стовпця в MS SQL Server. Працює! Стільки вдячності.

— BriOnH

1

Схоже, вам це доведеться робити щоразу, коли ви створюєте таблицю або щось подібне.

— Сонні Чайлдс

1

Це вище, як правило, є моїм рішенням, коли відбуваються дивні речі. У цьому випадку це не вирішило проблеми. Хоча перезапуск SQL Studio зробив свою справу.

— Dan Mehlqvist

9

Якщо ви запускаєте це всередині транзакції та оператор SQL перед тим, як це впаде / змінить таблицю, ви також можете отримати це повідомлення.

— Стагг
джерело

1

+1. Я змінив таблицю, додавши новий стовпчик заново, і отримував цю помилку в наступному операторі, що стосується нового стовпця. Я подолав це, виконавши висловлювання до зміни таблиці в один перехід, а потім решту в інший. Не найбільше рішення, але розблокували мене. :)

— Прасад Корхале

3

Я врешті-решт вимкнувся та перезапустив Microsoft SQL Server Management Studio; і це зафіксувало це для мене. Але в інший час достатньо було лише запустити нове вікно запитів.

— IAM_AL_X
джерело

2

Якщо ви використовуєте змінні з тим самим іменем, що і ваш стовпець, можливо, ви забули маркер змінної '@'. У викладі INSERT він буде виявлений як стовпець.

— Деван Кутзі
джерело

2

Просто була та сама проблема. Я перейменував деякі псевдонімні стовпці у тимчасову таблицю, яка надалі використовується іншою частиною того ж коду. Чомусь це не зафіксувало SQL Server Management Studio, і воно скаржилося на недійсні імена стовпців.

Що я просто зробив, це створити новий запит, скопіювати вставити SQL-код зі старого запиту до цього нового запиту та запустити його знову. Це ніби правильно оновило середовище.

— Яблучний пиріг
джерело

1

У моєму випадку я перезапускаю Microsoft SQL Sever Management Studio, і це добре працює для мене.

— Рекші
джерело

0

У моєму випадку я намагався отримати значення від неправильного ResultSet при запиті декількох операторів SQL.

— Діпак Катарія
джерело

0

У моєму випадку, здається, проблема була дивною проблемою кешування. Наведені вище рішення не спрацювали.

Якщо ваш код працював нормально, і ви додали стовпчик до однієї зі своїх таблиць, і він видає помилку "недійсне ім'я стовпця", а рішення вище не працює, спробуйте: Спершу запустіть лише розділ коду для створення цього зміненого таблиці, а потім запустіть весь код.

— LoMaPh
джерело

0

Включивши цю відповідь, тому що це був найкращий результат для "недійсного імені стовпця sql" в Google, і я не бачив тут цієї відповіді. У моєму випадку я отримував неправильне ім’я стовпця, Id1, тому що я використав неправильний ідентифікатор у своєму операторі .HasForeignKey в моєму коді Entity Framework C #. Після того, як я змінив його на ідентифікатор об'єкта .HasOne (), помилка зникла.

— Даніель
джерело

0

Я отримав цю помилку під час запуску скалярної функції з використанням значення таблиці, але в операторі Select у моїй скалярній функції RETURN відсутня частина "ВІД таблиці". : facepalms:

— cdabel
джерело

0

Також трапляється, коли ви забудете змінити ConnectionString і запитати таблицю, яка не має уявлення про зміни, які ви вносите на місцевому рівні.

— Іво Недев
джерело