AutoIncrement поле в Access таблица

Използвам база данни на Access.Достъпа до нея осъществявам чрез ADO компоненти.(Това не е толкова важно).Таблицата има AutoIncrement поле.Когато се изтрие запис от базата и след това се добави нов номерацията не е последователна, т.е. ако например записите са 6 и се изтрие един, при следващо въвеждане новия запис е с номер 7, т.е. пропуска се 6.Това обаче не е проблем за вътрешната организация на данните в таблицата.Проблема възниква когато се изобрази номерацията на данните например в DBGrid контрола просто не е гот , че номерата не са последователни.
Как може да се реши този проблем?

Не става ;-)))) - може да използваш 2 начина ако наистина ти е жизнено важно
1. Не ползваш Auto Inc - ами просто си взимаш последния номер и го увеличваш - това при условие че имаш само един клиент вързан с програмата. И това се прави в момента на запис на данните - само.
2. Ползваш някакво подобие на application server - една процедура с заключване - т.е. в даден момент само един клиент да може да получи брояча - но това пак не ти гарантира, че няма да имаш клиенти които ще се откажат от заявката - и ще се получи дупка - единствения вариант е да намериш механизъм който да ти уплътнява "дупките" ;-))) - виж това обаче ще забавя нещата
Въобще не мога да разбера каква информация ще носят някакво си поле което се увеличва - само заема място на екрана.

---
Е т'ва е живот!

Опитваш се да натовариш един инструмент (AutoIncrement) с неприсъщи за него задачи
AutoIncrement е инструмент, чиято единствена задача е да дава уникални (неповтарящи се) стойности. Те обикновено се използват за еднозначна идентификация на някакъв обект. "Дупките" не представляват никакъв проблем.
Последователното номериране без пропуски е най-често задача на изобразяването (много го обичат това счетоводителите) и трябва да се решава там, където се изобразява т.е. при клиента. Базите данни трябва да ги разглеждаш като ненаредени множества - следователно не може да има и поДреден номер
Ако наистина много държиш това да го решиш на страната на базата - вж. съветите и предупрежденията на Фантома.

Доколкото разбрах теб не те притеснява че при визуализацията срещу 6-то ID ще седи нещо което не съществува, тогава можеш да си поиграеш и да напишеш заявка чрез която да покажеш съдържанието на таблицата ти. Като заявката ще брои кой ти е записа и ще седи на мястото на AutoIncrement полето.
Май малко кофти решение давам, ама user-ите няма да се шашкат ;) , което теб те притесняваше.

Черпя бира, който предложи заявка (select expression)към Access таблица (MS JET4), която да номерира последователно върнатите редове.

Cherpq bira za koto napishe TField descedant kakto i kulturna funkciq koqto da go podkljuchwa kam TGrid taka che da se pokazwat poletata kulturno a ne "po-trudniq" nachin

------------------------------
I got a COMPILER, and I'm not afraid to use it!

мда, незнам дали ш ми присъдят бира, но лесното решение на проблема се нарича Calculated Field.

като цъкнеш /не е лошо като за вместо Click :-)))/ с десния бутон върху ADOTable компонента /в дизайн режим/ има опция FieldsEditor. Та избираш тая опция - ще се отвори едно джамче, с четири бутона на връо и празно по-доле. пак дясна мишка в това, празното, New Field.
даваш име и тип на полето /Integer/, за вид на полето /Field Type radio-то/ - Calculated.

после - пак десен плъх, Add All Fields или Add Fields - за да се виждат и други неща, не само тоя брояч.

после - на същата ADOTable й пишеш OnCalcFields обработчик, който изглежда така:

procedure TForm1.ADOTable1CalcFields(DataSet: TDataSet);
begin
if DataSet.RecNo = -1 then begin
DataSet.FieldByName('SeqNo').Value := 1;
end else begin
DataSet.FieldByName('SeqNo').Value := DataSet.RecNo;
end;
end;

те тоя код има грижата да пълни читава стойност за подредения номер. проверката за -1 се налага поради чтото за първия запис DataSet.RecNo е -1, което е странно, ама...

бтв, моето поле /създадено наръка/ се казва SeqNo, при теб - както го кръстиш.

--------------------------------------
Започва Път от моят праг...

Изчисляемо поле TFieldRecNo (FieldKind := fkCalculated;) за което:

procedure TForm1.DataSetCalcFields(DataSet: TDataSet);
begin
TFieldRecNo.AsInteger := DataSet.RecNo;
end;

... кеф ти в DBGrid, кеф ти в DBLabel...

Дали завиването на крушка е софтуерен проблем?

Според мен, действително правилния подход е тази задача да се реши на клиента. Но........... задачата поставена от neregistriran 19.08.03 16:25 (от мен NDeu 19.08.03 17:01 е само формулировката и бирата разбира се) не беше такава
И така - не получаваш бира защото:
- Не изпълни условието на задачата "select expression"
- Искам да отбележа, че предложения от теб метод не е приложим при наложено филтриране в OnFilterRecord

Конкурса продължава

Select t1.rID, t1.Field1, (Select Count(t2.rID) from Table1 t2 where t2.rID <= t1.rID) as SeqNo
from Table1 t1

Table1.rID - AutoInc, PK

как се държи с филтър - показва поредни номера на филтрираните записи без да се отчитат скритите?

--------------------------------------
Започва Път от моят праг...

погледни коментара на NDeu, не е съвсем коректно с Calculated...

--------------------------------------
Започва Път от моят праг...

Не бих препоръчал филтър на резултата от заявката, защото драстично се намалява скоростта на достъп при по-голям брой записи в резултата. А в случая става дума за голям резултат, ако съм разбрал правилно.

Филтър се допуска при малък брой записи, когато с изпълнение на една завка получаваме повече от един резултат и го изолираме с филтър.

И изобщо филтъра е за съвместимост с TTable от времето на Paradox tables.

Дали завиването на крушка е софтуерен проблем?

има моменти в които не може да се мине без него - примерно ако искаш да направиш филтър по калкулируемо поле или по сложно условие (което не може или трудно се реализира с SQL).
Sorry - ама вси4ко си има плюсове и минуси просто трябва да се използва при определени случаи. Аз реално само веднъж съм докарвал до подбно нещо - ама тогава клиента беше изпростял до безсъзнание и искаше да му се филтрира идиотски заявката не само по калкулирано поле ами и по още критерии зависещи от няколко калкулириеми полета ;-))). Като се има предвид, че полетата не са от вида А = +,-,*,/ - ами са сравнения и прочие - можеш да си представиш те колко време отнемаха да се изчисли всеки запис.
Освен това скоростта зависи от това което ще сложиш в проверката - и мисля, че намаляването е линейно ;-))) - все пак n записа * m msec за запис допълнително ;-)))). Реално го ползвах в големи заявки - > 1000 записа - и реално забавянето не е нетърпимо по голямо от това на самата заявка.


P.S. - не мисля, че има общо с Paradox-а - просто си е стандартна възможност - Paradox-a има много трески за дялане - ама нека да не му предписваме и несъществуващи такива

---
Е т'ва е живот!

Sorry - ама вси4ко си има плюсове и минуси просто трябва да се използва при определени случаи. - прав си.

Аз реално само веднъж съм докарвал до подбно нещо - ама тогава клиента беше изпростял до безсъзнание... - :)) и аз от филтри бял свят не съм видял.

И Paradoxa не беше лош. ;) Само дето трябваше да се работи с TTable, понеже TQuery не използваше индексите. И от там - скоростта - под всяка критика.

Дали завиването на крушка е софтуерен проблем?

Блестящо решение........

Обади се като минаваш насам

като наминавам къде? Елхово?!? мне, мерси, /ме е морски, неща да съм танкист :-))))

--------------------------------------
Започва Път от моят праг...