Як виправити поле - лічильник (ADO Access)
Випадковим чином, після тривалої експлуатації ADO+Access, у таблиці була виявлена помилка - поле "лічильник" перестало бути ключовим. Зробити його назад таким - не давали кілька чисел, що повторюються. Допомогло тільки видалення цього поля (т.к. виправити номер запису не можна), і створення його заново. Як програмно: - виявити цю помилку?
> поле "лічильник" перестало бути ключовим. поле "лічильник" і має бути ключовим. просто найчастіше використовується в цій зв'язці для сурогатних ключів. т.що якщо хтось(. ) змінив структуру таблиці, аксесс(jet) чинити опір не буде. програмісту типу видніше яка йому структура потрібна.
> Як програмно: > - Виявити цю помилку? 95% системних помилок сидять в 30-40 см перед монітором.
> - виправити (переіндексувати) значення даного поля? Видалити дублі (або записати нову послідовність, якщо видаляти не можна), відновити ключ - alter table . встановити бажане значення лічильника - alter table.
> або записати нову послідовність, якщо видаляти не можна природно змінивши попередньо тип на простий інтежер (alter table . ), і можливо навіть не відновлювати послідовність (якщо не критично, немає зв'язок на цей ключ) а просто "занилити" все, при зміні типу на лічильник воно начебто саме вважає.
1) на рахунок виявлення помилки в базі - я думаю найпростіше, це перевірити, чи є перше поле ID в таблиці - ключовим? Як це можна перевірити програмно? 2) дякую за підказку! тільки хотів уточнити: - змінюємо тип поля на Integer:alter table [назва таблиці] alter column ID Integer- очищаємо:Update [назва таблиці] Set ID = NULLЯк заповнитиполе наново (числами по-порядку)? Яке значення відповідає типу поля "лічильник", щоб потім з Integer його назад змітити? І як його зробити ключовим?
> Як заповнити поле заново (числами по порядку)? > а просто "занилити" все, при зміні типу на лічильниквоно ніби саме вважає.
> Яке значення відповідає типу поля "лічильник" довідкову інформацію без проблем можна отримати у довідці.
> І як його зробити ключовим? > відновити ключ - alter table .
Ок! - дякую! А щодо першого питання - чи є перше поле ID ключовим? Як перевірити?
> Чи є перше поле ID ключовим?
Звернутись до INFORMATION_SCHEMA
а сенс? саме поле не змінює тип/не стає не ключовим. це зробив ти (твоя програма) судячи з невгамовного бажання, навіть за помилки, відновлювати і змінювати структуру лише програмно.
і що вийде? ти одному місці програми ознаку прибереш ( " випадково сталося " ), іншому поставиш і посилання на ключ з інших таблиць " підуть лісом " т.к. порядок записів не гарантований. Чи не краще знайти джерело "випадкового образу"? замість того щоб городити "відновлення", яке вб'є весь порядок у базі.
Отже. 1) "Побилися" індекси у двох підпорядкованих таблицях. Їхня зміна ні на що не впливає (не прив'язані ні до чого). Як б'ються? - Можна лише здогадуватись. м.б. мережу, або одночасне створення двох записів! Поля "лічильники" в них я може б і не робив, але, почитавши розумні книги - зрозумів, що ключове поле обов'язково має бути в будь-якій таблиці. Чи можна без них?
2) Не спрацювало (або я не правильно роблю): ADOConnection.OpenSchema(siPrimaryKeys, VarArrayOf([Unassigned, Unassigned, "TablePL"]),EmptyParam, ADODataSetPL); ADODataSetPL.RecordCount завжди = -1
3) Спустошенийalter column ID Integer=>Set ID = NULLробити лічильником не дає - пише, що необхідно створити нове поле. Чи потрібно видаляти/створювати поле ID? або, як я вже питав - чи можна перезаповнити Integer і спробувати його зробити AutoInc?
Можна без ПК, але він обов'язково має бути.
> alter column ID Integer => Set ID = NULL це що за маячня? пиши українською. у сенсі у командах SQL.
> Значить потрібно видаляти/створювати поле ID? Як хочеш, але голос розуму за те, щоб не чіпати структуру бази в процесі експлуатації. (коней на переправі не змінюють. а якщо вже і змінюють то ретельно зваживши і обміркувавши все, і вже точно не автоматично в програмі)
> можна перезаповнити Integer і спробувати зробити AutoInc? можна, спробуй.
проблема лише тому, що основне призначення ПК це однозначна, у ньому, ідентифікація записи. і призначити повністю однаковим за значеннями записам різні ID ти не зможеш, природно запитом. т.к. за відсутності ПК ідентифікація утруднена, і байдуже, що це відновлення ПК і робиться.
>пиши українською. у сенсі в командах sql.Я ж написав раніше:- змінюємо тип поля на Integer: alter table [назва таблиці] alter column ID Integer - очищаємо: Update [назва таблиці] Set ID = NULLВсе спрацьовує! А ось назад – у AutoInc не робиться (не заповнюється автоматично), пише, що потрібно створити нове поле.
>не чіпати структуру бази в процесі експлуатаціїФактично вона залишається такою, як була. Не можу я залишити таблицю з побитим полем. Вручну допомогло тільки видалення цього поля, і додавання його наново (першим, зтим самим ім'ям). Нехай числа (номери) змінилися, як раніше написав - до них у мене нічого не прив'язано, додано просто для наявності в таблиці ключового поля - т.к. інші для цього не підходять (можуть повторюватися). Один раз добре - можна виправити і вручну, але надалі хотілося б, щоб наявність помилки визначалося автоматично, але, на жаль:>Не спрацювало ( або я не правильно роблю): ADOConnection.OpenSchema(siPrimaryKeys, VarArrayOf([Unassigned, Unassigned, "TablePL"]), EmptyParam, ADODataSetPL); ADODataSetPL.RecordCount завжди = -1і автоматично виправлялося.
> але в подальшому хотілося б, щоб наявність помилки визначалося автоматично. використовувати можна і так і так, залежно від побажання програміста. І якщо вже зараз переробив вручну, то такою вона і залишиться.
> і автоматично виправлялося. Ось це, якщо реалізуєш, буде ПОМИЛКА! т.к. при найменшій неточності ти так зіпсуєш дані, що їх неможливо буде відновити.
> Тоді підкажіть - як? Легко. табличними методами jet/dao безпосередньо.
До речі раз виходить видаленням/створенням поля і на значення тобі начхати, то чому просто це не реалізувати та й усе?
Так, зазвичай втрата первинного ключа закінчується катастрофою, відновленням не підлягає.
Вибачаюсь – проблеми з Інтернетом!
>це те, як ти спроектував/зробив структуру спочаткуЯ спроектував спочатку перше поле - лічильник, ключове! Після кількох збоїв тастиснень/відновлень виявилося описане вище. Не було передбачено змінювати структуру таблиці! Більше того – де Ви бачили поле лічильник, з дублями (двома однаковими номерами)? Якщо навіть захотіти – таке програмно не зробити.
Як виправив? - вручну видалив з битої таблиці (у режимі "Конструктора" таблиці в Access) поле лічильник, що перестав бути ключовим. Потім додав нове перше поле – ключове, лічильник. Він спитав щось на кшталт: "пронумерувати?" - "так." Все ОК! І базою знову стали нормально скористатися. Номер у полі лічильник мене не хвилює - воно мені потрібне виключно для запитів UPDATE. Це поле ні з якою іншою таблицею не пов'язане. Все працює!
Тепер – як організувати профілактику виникнення таких помилок? Як їх обчислити – я вигадав: запитом SELECT + COUNT я перевіряю поле "Номер" на наявність дублів. А ось – як виправити? - не придумаю ніяк. Основне питання - поле лічильник - як описати цей тип у запиті ALTER TABLE? Я з'ясував, що це довге ціле (в access - Long), з доповненнями. Але якими?Як вказати у запиті - властивість поля "послідовне"?
І ще одне - при додаванні поля, в кінці запиту пишу - FIRST, поле додається, але останнім, а не першим, як це хотілося б.
> Якщо навіть захотіти - таке програмно не зробити. не жартуй так -> CREATE TABLE CountTable (ID Counter, Name VarChar(30)) INSERT INTO CountTable (ID,Name) VALUES ( 1, "Test") INSERT INTO CountTable (ID,Name) VALUES (1, "Test") INSERT INTO CountTable (ID,Name) VALUES (1, "Test")
> поле лічильник, що перестало бути ключовим. воно не може перестати бути ключовим. скільки разів повторювати? і потрібно не профілактику робити, а виключати методи, що призводять до зміни структури. які в тебе могли бутинаприклад тут
> І ще одне - при додаванні поля, наприкінці запиту пишу - FIRST, поле додається, але останнім, а не першим, як цього хотілося б. Що за марення?
До речі, чим можна довести базу access до кількох відновлень? у мене за 10 років роботи з понад 10 тис інсталяцій, згадується 3 максимум 4 збою. а тут із однією базою кілька, дива.
чудеса в 30-40 см перед монітором