MS Access «өзгерістерді жазу» журналы

Жазба жойылған немесе пішінде жаңартылған кезде, ескі мәндерді журнал кестесінде сақтағым келеді (оны қайта қарастырайық). Менің ойымша, мынаны істеуім керек:

For record changes:

  • Деректерді бір жерде (коллекция жиыны немесе жазбалар жиынтығы - қайта қарастырылған кесте - сақтамай-ақ) сақтау үшін PreviousUpdate оқиға пайдаланыңыз
  • Бұл деректерді Жаңартылған кестеге қосу/сақтау үшін AfterUpdate оқиға пайдаланыңыз

For Deletions:

  • деректерді сақтау үшін OnDelete оқиғасын пайдаланыңыз, бірақ қалай қайтадан? пішінді (шын мәнінде ішкі формат) деректер кестесінің көрінісінде болғандықтан, бірнеше жазбаны бірден жоюға болады.
  • Бұл деректерді Жаңартылған кестеге қосу үшін AfterDelConfirm пайдаланыңыз.

Сізде қандай да бір жайттар, пікірлер немесе сілтемелер бар ма? Қазіргі уақытта барлығы «таза кіру» (ешқандай SQL Server). Көп рақмет !


Өңдеу: әдеттегідей, сауалға дұрыс жауап беру маған идеяларды береді:

1-нұсқа

SQL нұсқасын құру үшін BeforeUpdate немесе OnDelete пайдаланыңыз және AfterUpdate немесе AfterDelConfirm деген SQL нұсқауын орындау үшін пайдаланыңыз. Бірақ бұл бірнеше рет жою үшін жұмыс істемейді?

опция 2

қайта жазылған жазбалар жиынтығының деңгейін анықтаңыз, «Алдыңғы» жазбасын енгізіңіз, бірақ тек «Кейіннен» жаңартыңыз. Тағы да бірнеше рет жойылған мәселе.

2
Мәселе туралы ойланып, түпнұсқалық INSERT-ді қадағалау арқылы сіз әр жаңартудағы ескі/жаңа мәнді сақтау қажеттігін сақтайсыз. Бастапқы INSERT сізге түпнұсқалық «ескі» мән береді, ал соңғы UPDATE сізге ең жаңа мән береді.
қосылды автор Philippe Grondier, көзі
әдетте жасалатын (және басқаруға оңай) - SQL INSERT, UPDATE немесе DELETEs журналын сақтау. Бірақ менің ойымша, сіз мұнда жұмыс істеп жатырсыздар, олар басқарманың нысандарына тәуелді. Айтпақшы, дәл сіз нені қадағалағыңыз келеді? Барлық кестелердегі өзгертулер? бірнеше кесте? нақты салалар? пайдаланушыға?
қосылды автор Philippe Grondier, көзі
@Philippe G: 1 кестеге арналған барлық өзгертулерді қадағалауды (жоюды немесе жаңартуларды, кірістірулерді қадағалаудың еш негізін көремін)
қосылды автор Patrick Honorez, көзі
Белсенді рекорд тұжырымдамасы туралы: бұл шынымен жақсы, бірақ ... бұл логикалық өріс индекстелетін пайда аз болғандықтан, бұл барлық нәрсені баяулататын деп қорқамын, себебі әрбір сұрауда Active = True < code> condition, және бұған қоса кестені сканерлеуді күшейтеді.
қосылды автор Patrick Honorez, көзі
Ол «жойылған» деген ұғымды «белсенді» сияқты нәрсеге қайта анықтауға көмектеседі ме? Пішіннің жазба көзі WHERE active = True және active = False дегенді қамтуы мүмкін. Мұндай жазбалар жойылған жазбалардың тарихын сақтаудың қымбат емес тәсілі болуы мүмкін Қазір әлі де бар, бірақ пішінде көрінбейді.
қосылды автор HansUp, көзі
Кейбір сілтемелер: support.microsoft.com/kb/197592 және ofnisystems.com/index.htm (phps арқылы tek-tips.com сайтында дәйексөз келтірілген)
қосылды автор Fionnuala, көзі
IsActive өрісінің орнына DateDeleted өрісі болуы мүмкін. Ол аздап көп сақтау орны бар, бірақ ол индекстелуі мүмкін және сонымен қатар қосымша ақпарат берер еді (бұл бір уақытта пайдаланушы не істеп жатқанын түсінуге тырысқанда пайдалы болуы мүмкін). Әрбір сұрау кейін Active = True орнына DateDeleted Is Null шартына ие болады.
қосылды автор mwolfe02, көзі
Жазбаларды «таңбалау» идеясы үшін +1-ден @HansUp оларды жойғаннан гөрі жойылды. Сақтау әлдеқайда арзан болғандықтан, мен оны шынымен жою керек деп ойлаймын. Өнімділікке қол жеткізуге болатын сәттен бастап, пайдаланушыларға: «О, бұл жазбаларды өшіруді білдірген жоқсыз ба?», - деп айта аламын.
қосылды автор mwolfe02, көзі
Массажды қарастыратын тағы бір мәселе - бұл аудит ізін пайдаланушыларға қалай ұсыну керек екендігі. Пайдаланушыларға ыңғайлы, икемді, түсінікті және ыңғайлы шешім қабылдауға өте қиын. Сіз осы тізімнен ең маңызды екі атрибутты таңдауыңыз керек және үшіншіден құрбандыққа баруыңыз керек. Бұл шешім сіздің бүкіл дизайныңызға әсер етеді, сол себепті бұл фронтты түсіну маңызды.
қосылды автор mwolfe02, көзі

3 жауаптар

Мен әртүрлі жобаларда Allen Browne-ның көзқарастарын сәтті қолдандым. Қосымша ақпаратты веб-сайтынан қараңыз:

Аудит жазбасын жасау

Оның шешімі уақытша кестелерді және мәселені бірнеше рет жоюмен өңдеу үшін төрт жалпы функционалды шақыруды пайдаланады.

3
қосылды
Аллен Браун тамаша! Оның сайты - алтын кені!
қосылды автор Patrick Honorez, көзі

Мен жақында қараған тағы бір көзқарас, бірақ іс жүзінде іске асыруға мүмкіндігі болмады, өзгерістерді қадағалауды жүзеге асыру үшін мәмілелерді қолдануға болар еді. Негізгі алгоритм:

  1. use BeginTrans on the workspace prior to making any changes
  2. in the OnDelete event
    • perform the deletions in code executing Delete queries against the workspace from step 1
    • add a record to your change auditing table
  3. in the BeforeDelConfirm event
    • set Cancel = True
    • display your own Confirmation dialog
    • if user confirms then CommitTrans on workspace
    • otherwise Rollback the transaction on the workspace

Жаңартулар/кірістірулер үшін ұқсас тәсіл. Бұл уақытша кестелерге/массивтерге/жинақтарға қажеттілікті болдырмайды және т.б., бірақ мен барлық нәрсені ойладым. Дьявол егжей-тегжейлі болуы мүмкін.

3
қосылды
+1. Өте қызықты идея !!
қосылды автор Patrick Honorez, көзі
Рахмет @ mwolfe02 ... «Әрбір жазбаны жою үшін пішін оқиғасын жою бір рет орындалады.» Мен басқаша басқаша көз жеткіздім. :-(
қосылды автор HansUp, көзі
Мен өз ойымды жақсы білмедім, немесе сіз оны айттыңыз, мен жай ғана бұл туралы ойламаймын. Қалай болғанда да, менің жаман. Пайдаланушы тек ағымдағы жазбаны жойғанда, жазатын -ды табу оңай. Содан кейін, қарапайым жоюдың орнына немесе одан басқа бірдеңе жасаңыз. Бірақ, бір жою әрекеті үшін бірнеше жазбалар таңдалса, оларды анықтау керек. Міне, бұл мені шешуге мәжбүр. IIRC, сіз SelTop және SelHeight пішінін тексере аласыз, бірақ фокус фокустың басқа басқаруды ауыстырған кезде қол жетімді емес. Таңдалған жолдарды анықтау үшін қарапайым икемді альтернатива бар ма?
қосылды автор HansUp, көзі
+1 ұсыныстарыңыз үшін де. Деректер кестесінің көрінісінде таңдалған бірнеше жазбалар жалғыз амал ретінде жойылған жағдайда, оларды біріктірудің қиындықтарынан бас тартамын. Осы аспект туралы кез келген ойлар?
қосылды автор HansUp, көзі
Шындығында екі шешім де мәселені шешеді. Allen сайтынан: Пішінді жою оқиғасында, төмендегі код жазбаның көшірмесін уақытша кестеге жазады. Пішіннің AfterDelConfirm оқиғасында, бұл жазбалар, Access берген Access күйі аргументі жоюдың жалғасатынын көрсеткен жағдайда ғана шын аудит кестесіне көшіріледі. Уақытша кестедегі көшірмелер жойылады.
қосылды автор mwolfe02, көзі
Шын мәнінде, осы жауаптағы алгоритм осы мәселені шешу үшін арналған. OnDelete ішіндегі Cancel = True параметрін орнату арқылы, сіз ашық мәмілеге қарсы орындауға болатындықтан, сіз оларды жойылған міндеттерден алыстатасыз. Бұл пайдаланушы осы жоюдан шығып кетсе, транзакцияны қайтадан алуға мүмкіндік береді (жоюдың өзі де, өзгерістер тарихына қосылатындар да).
қосылды автор mwolfe02, көзі
Өңдеу: Мен бұны тексердім және Жою оқиғаларының барлығы жойылғанда, BeforeDelConfirm/AfterDelConfirm оқиғалары іске қосылмағанын түсіндім. Сондықтан Мен Cancel = True-ды BeforeDelConfirm оқиғасына ауыстырдым.
қосылды автор mwolfe02, көзі
Басқаша мәселе - BeginTrans-ты шақыру. Мен өзімнің жауаптарым бойынша жылтыратамын, бірақ оқиғалардың тәртібі жоюBeforeDelConfirmAfterDelConfirm . Яғни BeginTrans-ті бірінші Delete оқиғасынан бұрын ешқандай оқиға жоқ. Мен айтқанымдай, дьявола егжей-тегжейлі болуы мүмкін ...
қосылды автор mwolfe02, көзі
Жою нысаны оқиғасы әрбір жазба үшін жойылады. Егер пайдаланушы 5 жазбаны таңдап, Жою пернесін басса, онда Form_Delete 5 рет аталады, содан кейін Form_BeforeDelConfirm бір рет аталады, содан кейін Form_AfterDelConfirm бір рет аталады. Барлық Form_Delete's ( Cancel = True ) барлық әрекеттерін болдырмау Form_BeforeDelConfirm іске қосылмай тұруы мүмкін. Сондай-ақ, Form_BeforeDelConfirm әрекетін болдырмау Form_AfterDelConfirm-ті іске қосуға кедергі келтіруі мүмкін.
қосылды автор mwolfe02, көзі
Access алдымен DeleteDateConfirm және AfterDelConfirm оқиғалары арасында әр жазбаға арналған Delete оқиғасын екінші рет көтергенде жақсы болар еді. Мұндай нәрсені жеңуге оңай болады.
қосылды автор mwolfe02, көзі

Көптеген кестелер үшін іске асырылуы мүмкін «қарапайым» және жалпы шешім келесі кестелерден тұрады:

Track_Table
==================================================
id_track as primary key
id_table as name of the table which has been updated
id_primaryKey as the record identifier (the PK of the updated record)
changeType, being either DEL or UPDATE
changeDate, as dateTime value
fieldName, as text
oldValue, as text or memo
newValue, as text or memo

жаңартуды жасаған пайдаланушыны анықтау керек болса, жай ғана қосыңыз

userId

сіздің кестеңізде ...

Содан кейін, таңдалған пішіннің алдында және одан кейінгі оқиғалардан кейінгі жаңарту үшін «жаңарудан бұрын» және «жаңарту функцияларынан кейін» кейбір генериктерді жасай аласыз. BeforeUpdate функциясы ескі мәнді айнымалыға сақтайды, ал afterUpdate функциясы жетіспейтін деректерді толтырады және жол кестесінде жаңа жазбаны кірістіреді.

Тиісті кесте атауы мен өріс атауын білудің бір жолы болуы керек. Пішіндерде деректеріңізді көрсету үшін көріністерді немесе далалық бүркеніштерді пайдалансаңыз, бұл қиын болуы мүмкін.

Әрине, барлық кестелер бастапқы кілт болуы керек, сондықтан сіз жазба деңгейіндегі өзгерістерді қадағалай аласыз. Көптеген кен орындарында орнатылған ПК-лар, әрине, қиындық тудырады.

oldValues ​​және newValues ​​мәтінді түрлендіруге мәжбүр болады, сондықтан оларды мәтін немесе жазу өрісінде сақтай аласыз

0
қосылды