Helló Péter!
Remélem pár tanácsomat tudod hasznosítani.

"- Lenne ezzel kapcsolatban meg valami. Nem tudna valaki nekem Trigger-t
irni az automatikus sorszamozasra? Esetleg ha csinalt mar valaki
hasonlot elkuldene meddig jutott? Nekem egyenlore meg egy mukodo
Trigger-t sem sikerult osszehoznom. A legprimitivebb ertekadasra is
hibat ad."
Az automatikus sorszámozásra a legprimitívebb megoldás a közvetkező:
Pl. Előleg ezt már megcsináltad sqlplus-ban:
create table VALAMI(valami_ID number(7),valami_ertek varchar2(20));
create sequence VALAMI_SEQ increment by 1; 

Mikor jön az insert a programban, akkor a következő:
INSERT INTO VALAMI VALUES(VALAMI_SEQ.NEXTVAL, "valami");

Így triggerre nincs is szükséged, ha esetleg mégis triggeres megoldás 
kellene, akkor írj, és küldök egyet.

Üdv 
 József
UI: Ha Oracle-es kérdésed van, mindig írd meg a verziószámot is. Nagy 
különbségek lehetnek ! :)

Hello!

Koszi a valaszt!

>A hiba valószínűleg a Te készülékedben (project filédben) van.
igen, csak egyenlore nem tudom, hogy hol ugyanis az egesz egyben
build-elodik... sot, ha jol tudom, CodeGuard ki/be kapcs-nal ujrafordit
mindent... persze dll-re ez nem menne, de csak src-ket hasznalok es minden
egy project-en belul fordul... ezert volt a nagy elcsodalkozas...

>ez egy figyelmeztetés, hogy így értelmetlen CodeGuard-ozni.
>Valószínűleg semmilyen allokációs hibád nincsen.

Ebben mar biztos vagyok... megneztem az RTL src-t, egy static struct
pointeret adja vissza...

>BTW: a %i helyett nem %d-t szoktak használni?
Van kulonbseg? En ugy lattam, hogy ahol %d lehet ott lehet %i-is...
bocs, ha nem igy van... 

>BTW2: az egész bűvészkedés helyett sokkal egyszerűbb a
>TDateTime::CurrentDateTime().DateTimeString().c_str() használata.
>Ez ráadásul a Windows date/time formátumot használja, mindig
>a user beállításnak megfelelően. Persze ha saját fix formátumot
>akarsz, a TDateTime::CurrentDateTime().FormatString(...) is jó...

Igen ez igy igaz, de minek irjon az ember ketszer kodot (unix, win32), ha
nem muszaly... TDateTime teljesen jo, de csak win32 oldalon. A progi
viszont futni akar UNIX-on is...
(legalabbis a kozos resze, ez pedig az... )

Koszi a segitseget...

CodeGuard: mar eleg regota programozom, de mingi csak sajat "codeguard-ot"
hasznaltam #define-okkal malloc-ra free, re meg amire kell... jo latni,
hogy ilyen iranyban is fejlodnek az IDE-k...

Ide tartozo tovabbi kerdes: ismer valaki olyan util-t, ami a megadott
barmilyen src-ket (lehetoleg C-t es C++ tudjon) vegignyalazva
fuggvenyhivasi listat, esetleg osztalyhasznalati listat... Szoval egy
amolyan statisztika-jellegu dolgot gyartana a forrasokbol... Egy
egyszerubbet nem nagy ugy irni (idoben), de ott vannak a template-ek es a
leggazosabb a makrok vegigkovetese... vagy eleve az elofordito altal
generalt src-t kellene vegignyalni?

Megeccer koszi a CodeGuard helpet...

mean

 .-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
| Mészáros András --  |

Sziasztok koderek!
Valaki foglalkozik java kriptografiaval? Szuksegem lenne a
segitsegire!
Koszi.

Hali,

Lekodolod a progit C-ben, es beforditod linuxos es dos-os 
compilerrel.
Ez a nagy elonye a C-nek.

Udv:
Szaki

> >Az egyik friss ujsagCD-rol felraktam a freepascal 1.0-at egy gepre,
> >de akadt vele egy kis problemam. (ja igen, Win32 a kornyezet)
> >
> >A leforditas az IDE-n keresztul sehogy sem akar menni. CTRL+F9 utan
> >az IDE egyszeruen bezarodik, es az EXE sem keszul el. Ha a forrast a
> >parancssori compilerrel forditom, akkor jo.
> >[...]
>
> Egyreszt az IDE meg fejlesztes alatt all, tehat egyaltalan nem
> hibatlan. Masreszt az 1.0-s verzio sajnos eleg bugosra sikeredett, igy
> javallott egy ujabb snapshot (RTL+IDE) letoltese a
> http://www.freepascal.org cimrol. En csak azt nem ertem, hogy a Chip a
> CD-re miert nem rakott fel egy ujabb snapshotot is?
>
> Gabor

Sot! Azota mar kijott egy ujabb official verzio! Toltsed azt le! V1.0.2-es
verzio.
ftp://ftp.freepascal.org/fpc/dist/win32 vagy
ftp://ftp.freepascal.org/fpc/dist/dos

A teljes verzio dos+win32 kb. 20MB. Ha egyben jo, akkor eleg azt letolteni.

--
 .,--/'{[< Tcc of Inquisition >]}'\--,.

> Ha nincs erre megoldas akkor hol talalok valami leirast a linux-os
 > consol programozasahoz (ne irjatok azt, hogy forraskodot nezzek, mert
 > a bogaraszast a legvegsokre tartogatom :-) ).

console

/usr/doc/packages/ncurses/ncurses-intro.html vagy hasonlo (SuSE-n ez).
Ezenfelul man -k curses is sokmindent fog visszaadni.
Altalaban unix alatt a szabvanyos terminalvezerlehez a curses vagy
ncurses konyvtarat lehet hasznlani, amitol a programod gep es
terminalfuggetlenne valik.

Zoltan

Haliho!

Ehhez a legegyszerubb megoldas elkuldeni az IDE interface-nek
az identify magadat nevu parancsot, amire valaszul kiolvashato
egy szektornyi adat, ami a winchester parametereit tartalmazza...
(a nagyon regi winchiknel ez nem fog menni)
Ehhez az ide interface portjait kell irni/olvasni.
DOS, win9x alatt ez konnyeden megy (jo, az utobbihoz at kell menni
ring0-ba.. :-))  ), winnt alatt mas megoldassal
kell kisse varialni, mivel a port kozvetlenul nem erheto el.
Ajanlott freeware peldaprogik:
dos: Ranish fele particios manager
w9x, wnt: winio.dll + a a mellette levo pelda exe
Egyebkent az sem rossz, ha letoltesz egy kis ATA/ATAPI interface 
leirast a netrol, mert az is sokat homalyosit a kerdeskorben...

Udv
STeve

Hello!
Segitseget szeretnek kerni a palettakezeles ugyben.
TurboC 2.0-t hasznalok, es a grafikat most kezdem
tanulgatni es szuksegem lenne egy ertheto, lehetoleg
magyar (de angol sem baj) nyelvu tutorial-ra (a dolog
egy bmpnezegeto program kapcsan merult fel, igy kelle-
ne kezelni a monokromtol a 24bitesig).
A valaszokat elore is koszonom:
 Zsepi

Hali Coderek

1. Visual C++ 6.0 -ban *.mdb adatbazist szeretnek megnyitni. (ODBC-n
keresztul, vagy esetleg maskent) A Help-ben adott utasitasokat
felhasznalva sem kaptam meg a megoldast. Ha valaki tudja a megoldast
kernem szepen irja meg. (Tehat: a.) adatbazis megnyitasa b.) egy tablara
csatlakozas c.) kiolvasni egy erteket.

2 Ismeri-e valaki a lang (Fire, Flame) algoritmust, vagy tudtok-e
internetes oldalakat a temaban.

A valaszokat elore is koszonom : NagyI (Sze'kelyudvarhely)

Szia,


A CODER 0971-ban irta :
>Sziasztok!
>Egy kerdesem lenne a feni temval kapcsolatban.
>Mi is ez az egesz.
nos a wap rovidites feloldasa wireless application protocol. A celja az, 
hogy segitsegevel az internetes web oldalakhoz hasonlo oldalakat lehessen 
mobiltelefonrol elerni. Egy Borland bemutato alkalmaval volt szerencsem 
roviden megszemlelni egy wap-forrast. Lenyegeben a html-hez hasonlo, apro 
kulonbsegek voltak csak (persze, lehet, hogy sokkal nagyobb kulonbseget is 
lattam volna, ha jobban belemelyedek :-) ).

pl. a wap-oldalt card-nak nevezi, a site-ot meg deck-nek (paklinak), a 
forrasban a html, body stb. tag-ek helyet is ezeket a kifelyezeseket 
hasznalja.

Ja es a lenyeg: a html-lel ellentetben a wap nem ascii formaban kerul 
kisugarzasra, hanem leforditjak elotte binaris formaba -- a kissebb meret 
miatt.

>Tudom, hogy ez igy tul altalanos ezert egy kicsit szukitem:
>- programozoi oldal erkdekel
>- mikre kepes
>- mevel kell kesziteni
"sima" ascii editorral, bar a borland a JBuilder 4-et ajanlotta ra :-)

>Hozza kell tenni, hogy semmit nem tudok rola, tehat akar WEB oldal,
>konyv, kezirat, falfirka erdekel.
>Inkabb tajekozdasi szinten (elosszor), de konkret megvalositasok es
>otletek is esetleg.
>Magyaran hogyan kell olyat csinalni....
>Elore is koszonom


--
Udvozlettel,
 Zsanko Attila                              mailto:

p.s. Ment a listara is

>> >1. kulonboztessem meg a hosszusagokat???
>> Vagy mar a jelzobajtban, vagy valamelyik parameterben
>> jelzed/megkulonbozteted mondjuk a 8-bites, es a 16-bites
>> szamlaloju ismetlodeseket. Mondjuk a $55 prefixalja a
>> <karakter>+<8 bites szamlalo> es $AA a <karakter>+<16>
>> bites szamlalo tomoritett szekvenciakat. [...]
>Nem kotozkodom veled de "valtozo hosszusagu" RLE-n NEM
>ezt ertem. Szal amit leirtal az a normal RLE bajtokra.
>Arrgggghh, $55, $AA.
>
>Ha 7 bitet adnek a hosszusagra akkor 1-127 kozotti
>hosszusagokra lenne modom tomoriteni, de ha a hossz
>nem 7 bitet igenyel akkor felesleges biteket irok ki
>pl. 39 hoszzusagu szakasznal 1 bitet pazarlok (!!!)
>(a problema a 16 bitesre is igy igaz).
>Nekem nagyon fontos, hogy meg 1 bitet se pazaroljak.
Most vagy te nem ertesz engem, vagy en nem ertelek teged - de nagyon...

Szamomra a fejtegetesed kb. olyannak tunik, mint ha azert reklamalnal, mert
hogy 1000 darab kulonbozo szam tarolasahoz miert hasznalunk fel 10 egesz
bitet, amikor arra eleg lenne 9,9657 bit.
A tomorites nem arrol szol, hogy pontosan annyi bitet (helyet) hasznalsz
fel, mint amennyi az adatfolyam egyertelmu kodolasahoz szukseges. Az ilyen
"tokletes" tomoretis elmeletileg letezik, de gyakorlatilag nem (a
lehetosegek vegtelen szama es a feldolgozasi sebesseg es a tarolokapacitas
vegessege miatt).
A lenyeges, hogy a rendelkezesre allo informaciok es szabalyossagok
felhasznalasaval alakitsd ki, vagy talald meg azt az algoritmust ami adott
korulmenyek kozott statisztikailag (!) a legnagyobb foku tomoritest
eredmenyezi.

>> >2. jovok ra, hogy "0" sorozat jon vagy "1" sorozat???
>> Na, most akkor dontsd el, hogy bajtokat vagy biteket
>> kodolsz!
>Mar az elejen kozoltem a T. Listaval, hogy biteket.
>De azert csinalok belole ilyen szep nagy tombot (8x),
>hogy jobban kezelhessem (rulez Piroska :)))
Attol, hogy a bitekbol tombot csinalsz meg nem lesz jobban tomoritheto az
adatfolyam. Egy adott szekvencia mindig egy adott entropiaval rendelkezik.
Ezt te barhogyan transzformalhatod, amig nem veszel ki belole informaciot
vagy nem teszel ujabbat hozza, addig hiaba transzformalod, nem valik sem
jobban, sem kevesbe tomorithetove.

>> Ha biteket, akkor rendkivuli modon leegyszerusodik a
>> dolgod, hiszen nem kell mas tenned, mint folyamatosan
>> szamlalnod az egymas utan kovetkezo azonos biteket,
>> es amikor valt az ertek, akkor eltarolod a szamlalot,
>> majd nullazod.
>Eddig egyre gondolunk :)))
>
>> Kitomoriteskor egyszeruen veszed egymas utan az X db
>> biten (mondjuk 8) tarolt erteket, es annyi darab bitet
>> irsz ki a kitomoritett allamanyba, amennyit ez a szamlalo
>> meghataroz. Ezek utan negalod a kiirt bitet, majd veszed
>> a kovetkezo erteket es a negalt bitbol irsz ki n darabot.
>> Az egyszeruseg kedveert erdemes azt csinalni, hogy ha a
>> bemeneti folyam elso bitje mondjuk nem 0, akkor elsonek
>> egy zerus szamlalot irsz ki a tomoritett allomanyba.
>> Igy kitomoriteskor fixen 1 erteku bittel kezdheted  a
>> kitomoritest - ha nem ezzel (nem 1 erteku bittel)
>> kezdodott az eredeti bemeneti allomany akkor ugye 0
>> darab 1-est fogsz kiirni, ami utan a fentieknek
>> megfeleloen valt majd az aktualis bit-ertek,
>> es innentol kezdodik a tenyleges kitomorites.
>Az elejevel is 1-et ertek de:
>  ha van egy "11010110101" sorozat akkor buktal rajta.
>Az ilyen sorozato(ka)t nevezem "nem" tomorithetonek.
Ertsd mar meg, hogy nincs olyan algoritmus, ami _minden_ bemeneti adatsorra
_rovidebb_ kimeneti adatsort general! Minden tomoritesi algoritmus azon
alapul, hogy valamilyen modon informaciot "von ki" a bemeneti adatsorbol, es
csak a csokkentett informaciotartalmat tarolja (a tomoritett kimenetben). A
kivont es a kitomoriteshez szukseges plusz informacio maga a tomorito
algoritmusban rejlik (tarolodik), nevezetesen azokban a
szabalyszerusegekben, amelyet az algoritmust felismer, es kodol. Tokeletesen
veletlenszeru bemenet _nem_ tomoritheto (statisztikai ertelemben)! Egy
tomorito algoritmus csakis akkor lehet effektiv, ha bizonyos specialis (a
tomorito altal felismert es kodolt) tulajdonsagokkal rendelkezo adatsorra
engedik ra. Pl. az RLE az azonos jelekbol allo hosszu szekvenciakat, az
LZxx-ek az ismetledo szekvenciakat, mig pl. az aritmetikai tomorites a
statisztikailag egyenlotlen eloszlast mutato adatfolyamokat tomoritik
effektiven. Ha olyan adatsorra engedjuk ra oket, amelyek ezekkel a
tulajdonsagokkal nem rendelkeznek, akkor altalaban az eredetinel meg
hosszabb (de semmikeppen sem rovidebb) kimenetet kapunk.
Egy szonak is szaz a vege: a tomorito algoritmus
kivalasztasakor/kialakitasakor nem azt kell vizsgalnod, hogy van -e olyan
bementi adatsor, amit az adott algoritmus nem tomorit (vagy esetleg meg
hosszabban kodol, mint az eredeti), hanem azt, hogy statiszikailag (!)
effektiv -e a tomorites, azaz, hogy a potencialis bemeneti adatsorok kozul
tobbet tomorit -e rovidebbre, mint amennyin nem tomorit, vagy noveli a
hosszat.

>> >3. kezeljem a nem tomoritheto szakaszokat???
>> Tomoriteni mindent lehet - csak mas kerdes, hogy
>> a kodolt allomany kisebb lesz -e mint az eredeti.
>> Ebbol kovetkezik, hogy a koznapi ertelemben vett
>> "nem tomoritheto" szakasz nem attol nem tomoritheto,
>> hogy nem lehet rajta lefuttatni a tomorito (kodolo)
>> algoritmust (hiszen lehet), hanem attol, hogy
>> a keletkezett kimeneti adatsor nem lesz rovidebb,
>> mint a bemeneti, tehat a tomorites nem lesz effektiv.
>> Ez azonban sosem vonatkoztahato egy kiragadott
>> szekvenciara, hanem mindig a teljes allomanyt kell
>> vizsgalni (mert a kiragadott adatsor tomorithetosege,
>> es eredendo hossza nem feltetlenul van barmilyen
>> osszefuggesben a teljes allomany tomorithetosegi
>> mutatojaval).
>Ez szep volt, de:
> a kiragadott szakasz az tenyleg nem tomoritheto,
> de nem arra vonatkozott a kerdesem, hogy a tomorites
> erre a szakaszra effektiv legyen.
> Az egesz allomany tomorithetosegi mutatojat szeretnem
> minnel kissebbre letudni, es akkor mar igencsak szamit
> a nem tomoritheto szakaszok hossza.
Nem szeretem ismetelni magam, de megint elmondom: nincsenek "nem tomoritheto
szakaszok". Te mindig az egesz allomanyt (vagy annak egy blokkjat) tomorited
egy lepesben, es csakis ekkore egysegen kell vizsgalni azt, hogy a tomorites
effektiv -e vagy sem. Hiaba van nekem egy 200 bajtos fajlban 10-20 darab 3-4
bajtos ugymond "nem tomoritheto" szakaszom, ha kozben a maradek resz
rendkivul jol tomoritheto (pl. a maradek osszes bajt tisztan 0 vagy 1),
akkor akar rovidebb kimenetet is kaphatok, mint ha az egesz allomany ugymond
alapvetoen "tomoritheto" szakaszokbol allna, de ezek egyike sem lenne
annyira "jol tomoritheto" mint az elobbi esetben a maradek resz.
Tehat sosem konkret eseteket, es nem kiragadott sorozatokat kell vizsgalni,
hanem statisztikailag es mindig egysegeben kell kezelni a problemat!

> Lamma pelda 100 darab "0" 15 darab "1" es 111101011
> Az utolso sorozattal mi legyen?
>
>Eddigi osszefoglalo:
>
>Hagy bitet tudunk letomoriteni legalabb 1 bit haszonnal?
Ertelmetlen kerdes, hiszen mint az mar korabban mondottam volt: a
tomorithetoseg a bemeneti adatsor entropiajatol fugg, tehat altalanossagban
nem jelentheto ki, hogy x db bit _mindig_ max. y db bitre tomoritheto, mert
az osszes lehetoseg szambaveve mindig lesznek olyan elmeleti (!) bemeneti
szekvenciak, amelyeken nem erteheto el tomorites - fuggetlenul az
alkalmazott algoritmustol. A lenyeg, hogy a gyakorlatban (!) azok a bemeneti
szekvenciak forduljanak elo tulnyomo tobbsegben, amelyeken effektiv
tomorites vegezheto.

Mondom meg egyszer: gondolkodj! Nincs kizarva, hogy nehol en is hulyesegeket
beszelek ossze (ez esetben szivesen veszem a helyesbitest), de probald
megerteni es atlatni, hogy mirol beszelek, es hogy mi a hiba a te
megkozelitesedben!

Gabor