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.
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.
szvsz nem trigger. EntMan-ban rámész a táblára, jobb gomb, tulajdonságok. ott prmissions gomb. erre előjön egy ablak, ott látod, kiknek van joguk a táblára. alul van egy columns gomb. arra klikk, és ott oszlopokra megadhatod, hogy ki milyen műveletet végezhet rajta. Remélem erre gondoltál.
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.
azt mondja meg valaki, hogy mssql-ben van-e valami parancssoros utility adatbázis mentésre/visszatöltésre? mint a mysqlbackup, a pg_dump, az exp80 és társai?
szerintem két dolog közül választhatsz.
1. elkezdesz próbálkozni mindenféle más megoldásokkal, ettől vélhetően ideges leszel...
2. beszélsz a nagyon fontoskodó rendszergazdával, hogy van egy feladatod, amit _el_kell_végezned_ , és ehhez kellene egy kis támogatás az ő részéről. aztán ha még mindig fontoskodik, akkor gondolom van neki egy főnöke, meg van neked is egy megbizod, játszák le egymás között, hogy tudd a dolgodat végezni.
+1: próbáld meg a bakup file helyére beirni a saját gépedet. hátha megeszi.
igen, jol latod, eddig ezen a modon tudtam csinalni, hogy a backup file helye "\\gepnev\d$\backup..." formaban volt megadva.
Hat igen, a dbadminokkal az a baj, hogy ez egy nagyon nagy ceg, es teljesen hanyatt vannak esve a sajat fontossaguktol, vagyis szamukra egy fejleszto az csak valami szukseges rossz, egy kis zummogo szunyog.
hesss-hesss..
En meg nem nagyon csipem ha ilyen gagyi rutinfeladatokra ugy csinal valaki mintha a bolcsek kovet orizne, es erezzem magam megtisztelve.
Nem korrekt.
Vagy mindig a morcos homloku rendszergazdaknal kell ilyen trivialis dologert kuncsorogni? szvsz talán ez az egyszerűbb út. Bár úgy emlékszem, a backup esetén fel lehet venni helyeket, ahova ki lehet menteni az ab-t, bár ezt még nem próbáltam. próbáld meg a kliens-géped egyik share-jét oda felvenni, hátha sikerül.
Kosz.
Nos hat a kerdesem az lenne, hogy:
adatbazis mentest az ugyfel cegnel eddig enterprise managerben tudtam csinalni (backup database). A kapott file-t a fejlesztoi gepen 'restore', es maris ugyanazt az adatbazist latom, amit az eles rendszerben.
De most megkonfigoltak az eles adatbazist, ezert ez a modszer nem mukodik, csak a szerver particioira tudok dumpot csinalni, az meg nem jo, mert a gephez nekem feljesztonek nincs hozzaferese.
Kerdes az hogy lehet-e kliens oldalon valamilyen segedeszkozzel, eljarassal "backup/restore" kompatibilis allomanyt krealni?
(db_owner jogom meg van a tablakhoz)
Vagy mindig a morcos homloku rendszergazdaknal kell ilyen trivialis dologert kuncsorogni?
Igen, fent van. Teljesen magyar nyelvű Windows 2000-ről van szó. Magyar billentyűzet kiosztás, magyar területi beállítások, minden.
Azon gondolkoztam, hogy az lehet-e gond, hogy ezen a gépen csak sp1-es Win2000 van fenn?
Azon az ötödik gépen fent van a magyar (ill. közép-európai) kódlapok támogatása? Control Panel, International alatt van egy lista, ahol be kell pipálni, hogy fent legyen (ez angol nyelvű Windows 2000-re vonatkozik):
A következő problémám volna:
SQL2000 telepítésekor nagyon szépen felismeri a collation beállításokat 4 gépen. Egy ötödiken azonban nem.
Az említett négy gépen beáll szépen "SQL_Hungarian_CP1250_CI_AS" -re, azon az egyetlenen meg sehogy se tudom erre rávenni. Ott ilyen "Hungarian_CI_AS"-ra áll be, ami látszólag ugyan az, de valamiért mégis más.
Ebből az a gond jön elő, hogy a program adatbázisa "SQL_Hungarian_CP1250_CI_AS", a tempdb "Hungarian_CI_AS", így a varchar oszlopok összehasonlítása nem sikerül
(update table1 set valami = érték from table1 t1, table t2 where t1.varcharcol = t2.varcharcol).
Az a baj, hogy a telepítés során nem ezeket a belső konstansokat dobja fel, Így ott nem tudom konkrétan kiválasztani, hogy melyik kódlapot szereném, a rebuild master-nél már megfelelő listát kapok, de nekem az még egyszer se működött jól. Dolgozott 5 percet, majd fél óra inaktivitás után azt mondtam, hogy elég.
Nem írtad, milyen SQL Server, de ha van lehetőséged rá, akkor ne a "hagyományos" temp táblás megoldást használd, hanem próbáld ki a memória táblát. A használata pofonegyszerű, hátránya a temp táblás megoldással szemben, hogy nem indexelhető.
DECLARE @myLittleTempTable AS TABLE
(
@myLittleColumn1 int,
@myLittleColumn2 int
)
Innentől kezdve ugyanúgy használhatod, mint a temp táblát.
Let look at a simple CREATE TABLE statement.
CREATE TABLE #Yaks (
YakID int,
YakName char(30) ) You'll notice I prefixed the table with a pound sign (#). This tells SQL Server that this table is a local temporary table. This table is only visible to this session of SQL Server. When I close this session, the table will be automatically dropped. You can treat this table just like any other table with a few exceptions. The only real major one is that you can't have foreign key contstraints on a temporary table.
Van valami specko jelentese a # jelnek tabla nev elott? Mert a CREATE_TABLE #akarmi -re azt mondja hogy successful, de nem latom hol a tabla. drop-ra meg mar o sem latja.
Egy mukodo kodban lattam, szoval ertelme van csak en meg jottem ra. Amugy a tabla rendeltetese: kodbol hozodik letre, valami szamolas/osszegzes akarmi van benne, az eredmenyt kinyerjuk belole es aztan drop. Egyszoval temporalis.
Valami otlet?
Azon tűnődöm, hogyan lehetne megoldani, hogy egy dinamikus webhelynek az eredményül kapott lapjai egy más szolgáltatónál statikus de x időközönként automatikusan frissülő lapként megjelenjenek. Azaz: van egy asp oldalam amivel elérek egy adatbázist és a megfelelő lekérdezések eredményeként kapok egy oldalt. Ezt az (így már statikus) oldalt kellene eljuttatni (tulajdonképpen tükrözni) egy másik szolgáltatónál lévő webhelyre (tehát a weblap már nem tartalmaz programsorokat csak a kapott lekérdezés eredményét). Hölgyek, urak tipp? Üdv: axverda (ezt a kérdést feltettem a web szerkesztésnél is, bocsánat de fontos lenne)