Отмяна на промените в базата данни
Добър ден. Кажете ми как да върна промените в таблицата на базата данни, след като публикацията е обработена. Правилността на попълване на основната таблица на базата данни се проверява с помощта на SQL заявки, записани в отделна таблица. Но за да работи заявката, е необходимо данните да бъдат въведени в основната таблица, т.е. методът Post работи. Но ако се открие грешка в попълването, трябва да отмените промените. Как да го направим?
използвайте механизма за транзакции на използваната база данни. въпреки че подозирам, че тук архитектурата на приложението трябва да бъде поправена.
←→Alexander_2012 ( 2014-03-21 15:14 ) [2]
Има редица правила за попълване на основната таблица и те могат да се променят, така че проверката за коректност се поставя в отделна таблица. Затова просто не мога да си представя как да променя програмата. Как работи механизмът за транзакция? Можете ли да дадете пример или линк?
> [2] Alexander_2012 (03/21/14 15:14) > И как се активира механизмът за транзакции?И каква база данни можете да кажете в крайна сметка?
←→Alexander_2012 ( 2014-03-24 09:25 ) [4]
> [4] Alexander_2012 (03/24/14 09:25)Какво е тогава методът Post, ако има специален език - SQL се вика, има много неща по принцип, а в Oracle още повече. И по-специално всичко това се прави в рамките на транзакции. Не е необходимо да използвате всеки TTable.
> използвайки SQL заявки, записани в отделна таблицакак е?
←→Alexander_2012 ( 24.03.2014 10:40 ) [7]
> Заявки като: изберете Count(*) от table1 където pole1=1 > и pole2<>5защо не направите тези проверки преди да въведете данните?
←→Alexander_2012 ( 24.03.2014 10:50 ) [9]
> OraQuery е променен наOraTableТова е вълшебният метод.> И никой не е отменил метода Post в SQL.Какво-какво?> които операторът е въвел в DBEdits,Тук първо трябва да се изхвърлят. Има съхранени процедури, пакети. Прочетете за тях. И проверката на глупостите, които искат да вкарат БД трябва да е преди влизане. Там няма какво да носите боклук.
←→Alexander_2012 ( 24.03.2014 11:16 ) [11]
> И никой не е отменил метода Post на SQL.
Неточно се изразих, исках да кажа за компоненти работещи със SQL, т.е. OraQuery.
> което операторът е въвел в DBEdits,
Така че първо те трябва да бъдат изхвърлени.
Тези. Правилно разбрах, че вместо DBEdit е по-добре да използвате Edit и да го обработвате програмно?
> вместо DBEdit е по-добре да използвате Edit и да го обработите програмно?е, зависи от конкретната задача. Понякога е по-добре. Но и с DB-версии е възможно да се направи. Например TField.OnSetText, OnValidate
> Тези. Правилно разбрах, че вместо DBEdit е по-добре да използвате > Редактиране и програмна обработка?Няма значение откъде идва информацията. По добър (правилен) начин delphi-proger не трябва да мисли за структурата на базата данни. Базата данни трябва да реализира интерфейс за добавяне на определена крайна единица (документ, транзакция, отписване и т.н.) под формата на съхранена процедура.
Проверих данните, прехвърлих ги в хранилището и получих резултата.
> По добър (правилен) начин програмистът на delphi не трябва да мисли > относно структурата на базата данниТова е, ако delphi-proger има голям късмет и офисът има специално предназначен db-proger. Но не е винаги и навсякъде
←→Alexander_2012 ( 2014-03-24 11:28 ) [15]
Имам няколкоразделите визуализираха около сто полета от базата данни. Ако използвате Edit, тогава, когато превъртате през базата данни, ще трябва да напишете доста голяма част от кода, който ще актуализира информацията във всички редакции.
>TField.OnSetText, OnValidate Благодаря, ще помисля как това може да се използва за решаване на проблема.
> Това е, ако програмата delphi има голям късмет и офисът има > специален db-прогер. Но това не винаги е така > и то не навсякъдеИ тогава няма какво да гледаш Оракула :)
> Имам около сто > полета на база данни. Ако използвате Редактиране, тогава при превъртане през базата данни > трябва да напишете доста голяма част от кода, който > ще актуализира информацията във всички Редакции.
И кому е нужна такава визуализация? Информацията трябва да се показва, когато е необходимо, а не просто да бъде.
GUI - римейк; DB-архитектура - най-вероятно също.
И какво пречи да се вкарат данните в ? На същото място и всички проверки за изпълнение
> Изпълнете всички проверки на едно и също мястоНе винаги е възможно (удобно) да се правят проверки в HP, например валидността на TIN. Да, и това не е бизнес с бази данни :) Базата данни трябва да проверява валидността на своята архитектура, а не съдържание
> ако pole1=1, тогава pole2 трябва да бъде равен само на 5такива проверки е най-добре да се правят на клиента. с издаване на съответното проклятие при отказ или ограничение в самото управление
Е, да, не е така да пишете боклук в базата данни, за да я проверите, дори ако транзакцията постоянно се връща назад.
> въпреки че със същия TIN не е трудно да се провери на сървъра.
> Да, добре, nafig, на същото място изхвърлянето се превключва.+ и след това товаработата е просто GUI, потребителят трябва да види какво въвежда.
←→Alexander_2012 ( 2014-03-24 15:14 ) [25]
Необходими са всички полета за визуализация. Да кажем подробна информация за обекта.
>И тогава няма какво да гледате Оракула :)
Без избор базата данни не е генерирана от мен, не мога да променя нищо в основните таблици, но трябва да я използвам и да създам удобен инструмент за операторите.
>Какво ви пречи да вмъкнете данни в HP? На същото място и всички проверки за изпълнение
Операторът, въвеждайки стойности в клетките, може да направи грешка, точно като лицето, предоставило информацията, следователно, когато запазвате (в идеалния случай), всички съществуващи връзки се проверяват и ако се открие грешка или грешки, записът в базата данни трябва да бъде блокиран със съобщения за грешка.
>Е, да, не става дума за писане на боклук в базата данни с цел проверката й, дори транзакцията постоянно да се връща назад.
Разбирам това, но не се сещам за друг начин за прилагане на многократни проверки (днес около 60), а условията и броя на проверките можем да променяме 1-2 пъти годишно. Тези. имате нужда от възможността лесно да променяте условията на проверката. И писането на анализатор на низови изрази е много трудно.
> анализатор на низови изразиако условията не са много объркващи, тогава е достатъчна таблица във формата Поле FieldValue DependentField DependentFieldMin DependentFieldMax ----------------------------------------------------------------- Pole1 1 Pole2 5 5 Pole1 1 Pole3 10 15 е достатъчна.
> Необходими са всички полета за визуализация. Да кажем подробен > информация за обекта.Не разказвайте само приказки. Така че е директно всички полета наведнъж на всички "обекти". Не вярвам.
> Няма избор на база даннине е генериран от мен, промяна в основния > Не мога да правя нищо в таблици, но трябва да го използвам за оператори > за създаване на удобен инструмент.Няма спор за избора на СУБД, само няма програматор за него в доставката
> Разбирам това, но не мога да измисля друг начин за прилагане на > множество проверки (днес около 60), > освен това, условията и броя на проверките, които можем да променим > 1-2 пъти годишно. Тези. трябва да можете лесно да променяте условията > чекове. И писането на анализатор на низов израз е > много трудно.
Не е нужно да измисляте. Всичко отдавна е измислено и дори разказано.
И за да бъда честен, учебникът по PL-SQL в зъбите и гризат, гризат, гризат. започвайки със самите основи: SELECT, INSERT, DELETE, JOIN, .
> освен това, условията и броя на проверките, които можем да променим > 1-2 пъти годишно. Тези. трябва да можете лесно да променяте условията > чекове. И писането на анализатор на низов израз е > много трудно.Сложих тази логика (на същия TIN и т.н.) в dll преди много време,
←→Kshd ( 2014-03-24 19:19 ) [31]
>Alexander_2012 (03/24/14 15:14) [25] OFOMS?
Проверките за валидност на данните обикновено се изпълняват чрез проверки и референтни ограничения за интегритет и тригери, които се задействат при добавяне/модифициране на записи. Тези механизми трябва да бъдат проучени в документацията за използваната СУБД.
> Проверките за валидност на данните обикновено се изпълняват чрез проверка и препратка > intergity - ограничения и тригери, които се задействат на > добавяне/промяна на записи. Тези механизми трябва да бъдат изследвани > съгласно документацията за използваната СУБД.:)))
> проверка и референтна целостта-ограничения и тригеритова вече е последната граница, ако потребителят е успял да пробие останалата част от валидирането клиент-сървър. и референтната цялост изобщо не е свързана с валидността, а с целостта на данните
> така че тук вече не става въпрос за валидност, а за целостта на данните > се прилага
Дали тези концепции са нещо съществено различно от гледна точка на областта на приложение? Според мен абсолютно нищо.
> Тези механизми трябва да бъдат проучени в документацията за използваните > СУБД.Златни думи. Излято в злато, под стъкло и на стена. Към автора - изхвърлете GUI, блъскайте си главата в стената, за да забравите завинаги думи като DBEdit и т.н. ЗАВИНАГИ да се забрани директният достъп на потребителите до масите, трябва да е в кръвта. Трябва да изградите GUI, сякаш ще бъде използван от саботьори, които мечтаят да съсипят базата данни. Запознайте се подробно с HP и тригерите, те ще ви помогнат да решите проблема си. И още нещо - нормален човек може да обработи с мозъка не повече от 17-20 "информационни обекта" наведнъж и това е границата, а нивото на комфортно възприятие завършва на 10 обекта, така че показването на повече от 10 реда данни или повече от 10 характеристики на който и да е обект е безсмислено, не се възприема. Необходимо е да групирате различни второстепенни характеристики, да ги премахнете от екрана и да ги покажете само чрез натискане на бутона "подробности" отделно.
> Необходимо е да се групират различни вторични характеристикиPageControl rocks
по тема - за добавяне на полето изтрито поставяме знак се изтрива, ако е правилно - премахваме знак.