>De igy megteheti azt, hogy a program felhasznaloi feluletet megkerulve
>egy sima sql promptbol kiad egy insert-et CSUPAN a szamla tablara, es
>NEM hoz letre uj rekordot a penztar tablaban, elrontva ezzel az
>adatbazist. EZT nem szabadna megengeni. De ha nem adok neki instert
>jogot, akkor szabalyosan - a felhasznaloi feluleten keresztul - se tud
>majd felvenni szamlat.

Ezt SZVSZ nem tudod a priv-ekkel megoldani. Esetleg a jelszavakkal,
host-okkal lehet jatszani.
En pld. ezt csinalnam: egy user, akinek csak te+a program ismeri a
jelszavat, lekerdi a user jelszavat vmilyen tablabol a jelszavakat (csak te
ismered az adatbazis hozzaferesi jelszavait, bekodolva megse legyen), es
utana ezzel csatlakozik.

Ilyen forman nem tud senki hozzaferni az adatokhoz.
Most nagyhirtelen ez jutott eszembe:)

bye & best regards: Kulcsar Zsolt

Sziasztok!

Delphi 6-ban irok egy programot, melynek tobbet kozott resze WAV fileok
konverzioja is. Az eddigi mono -> stereo "konvertalast" nagyon egyszeruen
oldottam meg: a monocsatornat lemasoltam ketszer. De hat ez annyira
nevetseges, hogy azzal kezdtem probalkozni, hogy megprobalok "alsztereot"
csinalni belole fazistolassal. Az elso problakozas, hogy megtolom a jobb
csatornat 10-20 ms-mal kesobbre ugyan hatasosnak nevezheto, de valojaban
csak atkozott visszahang.

Mar ejszakakat toltottem a neten, hogy valami hasznalhato forraskodot
talaljak a dolog megoldasara.

Ha jol tudom (de nem biztos, hogy jol tudom), szet kell bontani
meghatarozott szamu frekvenciakomponensre a gorbet, es a komponensek fazisat
kulon-kulon meghatarozott szoggel el kell tolni. Addig jutottam, hogy
valahogy Fourier-transzformacioval (eleg az FFT) kene nekiindulnom, de mar
ahhoz se talaltam forrast, csak kesz unitokat (regebbi Delphikhez). Neztem a
programmersheaven.com -ot a DSP, de nem sikerult. Probaltam matematikai uton
is, de mivel az eredeti matematikai modszer integrallal szamol (eleve
"vegtelen"), nem tudom, ezt digitalisan hogy lehet megoldani.

Abban remenykedem, hogy valaki tud itt nekem segiteni.
Bemenet:
^array [1..n,1..2] of integer {16-bit eleve 2 csatornas mono wav};
n:int64;
szog : integer;

Mark

"There are no constraits, no boundaries and no limits."

Ha nem kotod a felhasznalo orrara az adatbazis eleresehez szukseges
nevet es jelszot,
hanem azt a program kezeli, tole belepeskor egy attol eltero, az
alkalmazashoz szukseges
nevet/jelszot ker, akkor kivulrol nem fogja tudni manipulalni.

Rocky

> De igy megteheti azt, hogy a program felhasznaloi feluletet megkerulve
> egy sima sql promptbol kiad egy insert-et CSUPAN a szamla tablara, es
> NEM hoz letre uj rekordot a penztar tablaban, elrontva ezzel az
> adatbazist.

(1)
Ha ennyire szorosan ossze kell tartozni a rekordoknak, akkor nem lenne
celszerubb egy adatbazisban tarolni oket? (Nem 2 rekordban hanem egyben).

(2)
Irasi joggal rendelkezo felhasznalo ilyen elven barmit elronthat.
Foleg ha szandekosan csinalja. Inkabb azt kellene megakadalyozni,
hogy ilyesmihez hozzaferjen.
Ja, es akkor meg mindig ott a lehetoseg, hogy interfeszen keresztul
fiktiv adatokat vigyen be... :-/

Andras

>Felado : Guban Peter
> > >Lehet adni jogosulsagokat a felhasznaloknak, mint olvasas, iras, append,
> > >stb... Azt hogy lehet megcsinalni, hogy az iras az ne lehessen
> > >akarhogyan? A felhasznalo ne ronthassa el az adatbazis konzisztenciajat.

Úgy tűnik, az adatbáziskezelőbe beépítettnél finomabb/egyedi jogosultság
szinteket akarsz létrehozni, hogy megakadályozd a magasabb szintű logikai
hibákat, amelyeket az adatbáziskezelő hagyományos eszközeivel (pl foreign
key) nem tudsz meggátolni.

Tanács:
- először is a feladat legnagyobb részét bízd rá az adatbáziskezelőre, tehát
ahol csak lehet, használj foreign key-t. Nem kell programozni és tuti biztosan
jól, hatékonyan működik.

Ahol ez már nem elég, oda a tippem:
- csinálj saját "UserRight" táblát, amit a mezei userek csak olvasni tudnak,
és a fő admin(ok) tudják csak insert, update, delete művelettel elérni.
Ebben legyen pl 3 oszlop: TaskName char(30), UserName char(30),
IsEnabled char(1)
A táblába írod be hogy melyik usernek mi engedélyezett. A logikai
flag a végén csak a kényelmesebb használat miatt javasolt.

- minden adattáblának vond vissza a jogait a mezei userekre
- minden adatkezelő műveletre csinálj függvényt. pl legyen 
RaktarKeszletCsokkent
függvény, ha ki akarsz venni 1 db terméket a készletből.
- minden ilyen függvény azzal kezdje, hogy megvizsgálja a UserRight 
tábládat, hogy
a bejelentkezett user névhez (ezt le lehet kérdezni) van-e engedélyezett
"RaktarKeszletCsokkent" bejegyzes. Ha van, mehet a dolog, ha nem, kilepni.
A függvény paraméterei pl Cikkszám és Mennyiség

Ennek a megoldásnak sok előnye van
- pl pénzügyi rendszer szempontjából kívülről elemi műveletek végezhetőek
csak benne (tehát pl nincs olyan hogy kivesszük a raktárból de
elfelejtjük beírnia ezt a naplóba).
- ha kombináljuk tranzakció kezeléssel, igen megbízható rendszert kapunk
- teljesen elrejti az adatbázis belső szerkezetét, az gyönyörűen
módosítható a függvények mögött, pl egyes program verziók között

Jelentős hátrányai is vannak:
- kifinomult PROCEDURE kezelést igényel az adatbáziskezelőtől, ez nem
mindenhol áll rendelkezésre
- a procedure kezelés abszolút nem szabványos, a megoldásod nem lesz
hordozható, mindig újra kell írni, ha adatbáziskezelőt váltasz
- sokkal gondosabb tervezést igényel, jóval több időbe kerül a megvalósítás.
- a userek nem tudnak feladni ad-hoc lekérdezéseket, csak olyat, amilyet
te beletervezel a rendszerbe, ezzel jelentősen csökken a rugalmasság

Szóval kompromisszum...

Szerintem ez csak szigorú biztonsági politikával rendelkező
nagyvállalati környezetben lehet csak indokolt, ahol
tényleg szükség van ilyen kifinomult user right kezelésre és
ennek fontossága sokkal nagyobb, minthogy ad-hoc lekérdezéseket
lehessen végrehajtani.
Nagy munka.

Józsi