Keresés

A FOR trigger az az AFTER trigger ("AFTER is the default, if FOR is the only keyword specified.")

Az INSTEAD OF problémához sok sikert kívánok... :) Egy ötlet: A trigger futásakor a törölt (módosított)  sorok benne vannak a "deleted" virtuális táblában, míg az új (módosult) sorok az "inserted"-ben. Na, szükség esetén írd vissza az új adatokat a régire. Ez akkor működik, ha a trigger a módosítás után fut le (ez valószínű, hiszen ez after trigger), illetve ha ez a visszamódosítás nem eredményez új trigger indulást. Szerintem nem.

a tranzakcióban csak egy sor van? akkor miért van szükség az insert tranzakcióba foglaláshoz? vagy sikerül vagy nem. nem? :) fele nem fog végrehajtódni.

és milyen isolation level van beállítva? ha valahol a programod lockolja a táblát, és az isolation level pl. serializable, akkor a programod elakad és a táblát nem tudod megnyitni, míg le nem lövöd a programot (illetve amíg meg nem szűnik a lockolása). mondjuk azt nem tudom, hogy a végrehajtás akkor miért jelent sikert. a c++-s függvényeket nem ismerem.

én 2000-es servert használok, az pedig az msdn szerint "The SQL Server 2000 ODBC driver complies with the ODBC 3.51 specification."

Bocs, egy kicsit más.

Downgrade-elnem kell SQL2000-ben írt triggereimet SQL7-re.

Van valakinek ötlete, mit lehet az instead of és after triggerekkel csinálni?

SQL7-ben csak for trigger van!

Sikerült tárolt eljárást hívni, igaz nem C-ből, hanem VB-ből, de ugyanazt az ODBC-t használja mindkettő.

Hogy néz ki az a tárolt eljárás?

Az id sorrend nem egyezik meg az order by sorrenddel. Egy-két helyen ugrás lesz.

Kivételesen nem kérdezek, hanem egy tapasztalatomat osztanám meg veletek.

Egy lekérdezés eredménének a sorait szeretném sorrendben megszámozni.

A sorszámot az id nevű oszlopba akarm írni.

Elvileg ennek működnie kéne:

select 
    identity(int,1,1) id,
    field1,
    field2,
    field3

into #tmp
from 
    MYTABLE

order by
    field1,

    field2;

De ez sajnos hibázik.

A jó megoldás:

create table #tmp(

    id int identity,

    field1 int,

    field2 datetime,

    field3 varchar(20));

insert into  #tmp (
    field1,

    field2,

    fied3)
select 
    field1,
    field2,
    field3

from 
    MYTABLE

order by 
    field1,
    field2;

Nekem úgy tűnik, hogy ez jól működik.

Érdemes ezzel vigyázni!

Jé, ez így működik!

Köszi szépen!

gondolom ilyesmi:

CREATE trigger dbo.block_update_THistory
on dbo.THistory instead of UPDATE
as

 UPDATE dbo.THistory SET field01=inserted.field01, field02=inserted.field02, ...

  FROM inserted

  WHERE dbo.THistory.ID = inserted.ID and

 100*year(THistory.dt)+month(THistory.dt)>(select closed_month from TCONFIG)

megj.:

- update trigger esetén 2 virtuális tábla áll a rendelkezésedre: a deleted-ben vannak a módosított rekordok régi, az inserted-ben az új adatai.

- természetesen a SET utáni részt a mezőnevekkel kell módosítani

Sziasztok!

Havi zárást szeretnék úgy megoldani, hogy alkalmas triggerek ne engedjenek adott dátumnál régebbi rekordokat módosítani.

Törlés kivédésére jó pl. egy ilyen trigger:

CREATE trigger dbo.block_delete_THistory
on dbo.THistory instead of DELETE
as
delete THistory
    from THistory
    inner join deleted
    on THistory.id = deleted.id
    where 100*year(THistory.dt)+month(THistory.dt)>(select closed_month from TCONFIG)

Ez a trigger a THistory táblából csak a TCONFIG.closed_month-nál újabb dt-jű rekordokat engedi törölni, működik is szépen.

De hogy lehet vajon ilyet csinálni update-re?

Any suggestions would be greatly apprecited.

az összes usert nem tudod lekorlátozni, mert a dbo standard role jogai nem módosíthatók.

ettől eltekintve működik az, amit gondolsz

hozz létre egy role-t az adatbázisban. nevezzük ezt most pl "myrole"-nak

ehhez rendeld hozzá azokat a jogosultságokat, amiket szeretnél engedélyezni (permission gomb a myrole adatlapján). Ezt egyszer kell megcsinálnod.

Utána az összes usert, akit beengedsz az adatbázisba, a public role mellett a most létrehozott myrole-hoz is rendeld hozzá (a public-hoz muszáj), és ezzel olyan jogai lesznek, amit te beállítottál a myrole-nak. ha a myrole-t változtatod, akkor az összes user jogosultsága változik. egyetlen különbség az általad kívánt "all users"-sel szemben, hogy ebbe a role-ba bele kell venni a usert, amikor beengeded az adatbázisba.

Tnx.

Nekem már csak egy olyan csoport kellene, mint a opszerveren az "all users", azaz az összes user jogát tudjam korlátozni.

akkor a usereket tedd bele egy groupba (role) és annak szabályozd a jogosultságát.

a trigger nem erre való.

de ha már mindenképp triggerelni akarsz, akkor tegyél fel egy INSTEAD OF triggert, ami a módosítás helyett hajtódik végre.

A megoldás jó is lenne, de nekem az összes userre kellene ezt alkalmaznom, ami elég macerás lehet, ha pl. valaki létrehoz egy új usert, és erre nem figyel.

Ezért lenne jobb megoldás a trigger szerintem

Lehet, hogy nem ide kellene írnom a kérdést...

Egy táblában akarom letiltani, hogy bizonyos mezöket modosíthasson akárki is.

Tehát felveszi a rekordot, és a védett mezö értéke a rekord törléséig nem szabad hogy változzon!

Ha jól sejtem Triggerrel kellene megoldani, csak nem tudom a parancsot megfogalmazni SQL-ben (sajnos sokat progiztam Pascalban, VB-ben és a halmazelvü programozás távol áll még tölem)

ADODB-vel és MSSQL-200 serverrel kapcsolatos kérdésem lenne. (A Visual Basic topikban már feltettem ezt a kérdést, de nem jött rá válasz, hátha itt igen.)

Tulajdonképpen csak annyi, hogy ha egy táblán valaki épp egy commitálatlan update-et hajt végre, akkor egy másik felhasználó hogy tudja azt a táblát közben egy ADODB.recordsetbe beolvasni.

A MSSQL Query Analizerből ez a következőképpen megy:
Nyitok két connectiont, két különbző taskban.
Mindkét ablakban kiadom a SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED parancsot.
Ezután az egyik ablakban a Begin transaction és update parancsokat adom ki (se commitot, se rollbackot még nem).
Ekkor a másik alakban vidáman látom a még commitálatlan módosításokat is.

Ezt az Quer Analizer / ADODB.recordset párossal a következőképpen próbáltam:
Adodb.connection.IsolationLevel = adXactReadUncommitted -et állítottam be,
az adodb.recordset-ben .LockType = adLockReadOnly-t.
A Query anaizerben: set TRANSACTION ISOLATION LEVEL READ UNCOMMITTED.

At vártam, hogy ekkor tudok az illető Adodb.connection-oz tartozó recordsetbe olvasni akkor is ha közben a Query Analizerben ott a comitálatlan update, de nem megy. A recordset addig nem hajtja végre az .open parancsot, amíg a Query Analizerben le nem zárom a tranzakciót.

Hogy lehet ezt megcsinálni?

backup:

OSQL -S sql_server_name -U sa -P sa_password -Q "backup database your_database_name TO DISK='c:\backup_folder\your_database_backup.bak'"

restore:

OSQL -S sql_server_name -U sa -P sa_password -Q "restore database your_database_name FROM DISK='c:\backup_folder\your_database_backup.bak'"

vagy osql.exe, ami futtat SQL scripteket.

Koszi,
S.