Na várj, maga a dokumentumod UTF-8 kódolású?
Notepad++-ban Formátum menüben tudod megnézni (melyik előtt van a pötty). Ami neked kell, az az "UTF-8 kódolás BOM nélkül", ha nem erre van beállítva, akkor menj az "Átalakítás UTF-8 kódolásra BOM nélkül" menüpontra (így nem kell újraszerkesztened a fájlodat az ékezeteknél).

Sk8erPeter

köszi, megnézem ezt a Notepad++-t.
a dokumentum alatt magát a weboldalt érted, ugye?

Hali!
Hát igen, a php, html vagy egyéb kiterjesztésű fájlodat, amiben az oldal forráskódja található.

Sk8erPeter

Sziasztok. Megint én...
Hogyan tudok egy olyat csinálni, hogy egy belépésnél amikor rá kattintok a belépés gombra akkor egy txt-be elmentse a felhasználó nevemet és a jelszómat?
Szóval: Felhasználónév: (Ide be írom a fh-nevem) Jelszóide be írom a jelszóm) és rá kattintok a belépésre és az be írja pl egy felhasznalo.txt-be. Na most ennek adnék egy 777-es atributot.... Na erre valami program kódot tudnátok adni, hogy hogy tudnám ezt meg oldani? Előre is köszönöm Üdv

Vagy valami rávezetés, tutoriál, vagy akármi is jól jönne

[ Szerkesztve ]

Miért akarsz 777 jogot adni? Hogy bárki hozzáférhessen? Nem túl jó ötlet, bár már önmagában az sem jó ötlet, hogy kiírod egy txt-fájlba ezeket az adatokat, főleg hash-elés nélkül. Nem is értem a célját.
Számtalan példa van a php.net-en az fwrite(), file_put_contents() függvények használatára, akár onnan ki is másolhatod (a fájlnevet átírva persze), elég egyértelműen vannak kommentezve.
Abba a fájlba tedd a fájlírást, amelyikben az űrlap feldolgozását végzed.

Az egyik példa alapján lehetne a következő, persze ellenőrzések után (csak egy-két dolgot módosítottam a megtalálható példán):
<?php
$file = 'felhasznalo.txt';
// The new user to add to the file
$user = $_POST['username'] .' | '. $_POST['password'] . "\n"; // függőleges vonallal elválasztva név | jelszó formában
// Append the contents of $person to the file named by $file.
file_put_contents($file, $user, FILE_APPEND);
?>

Ez mindig hozzáfűzögeti a megfelelő sorokat a fájlodhoz (ha nem akarod, hogy hozzáfűzzön, csak átírjon, akkor ne állítsd be a FILE_APPEND flaget).
De még egyszer mondom, ez ebben a formában nagyon nem jó ötlet, hacsak nem szeretnéd, hogy könnyedén hozzáférjenek a védett tartalomhoz!

[ Szerkesztve ]

Sk8erPeter

kösz a segítséget, sikerült meg oldanom. a 777-etet át álítottam, így most senki sem látja, csak én ftp-n keresztül....

Sziasztok!

Lehet, hogy már szerepel ebben a topikban az alábbi probléma, de nem találtam, ezért úgy gondoltam, hogy beírom.

Van egy lekerdezes.php, illetve egy popup.php fájlom.
A lekerdezes.php-ban van egy adatbázis lekérdezés, a popup.php pedig tartalmaz egy szöveget, s a végén pedig egy BEZÁR gombot. Természetesen a popup.php egy felugró ablak, amit az index.php-ból szedtem elő.

A BEZÁR gomb a következőképpen lett létrehozva:
input type=submit onclick=javascript:window.close() Value=Bezár>

Azt miképpen lehet megoldani, hogy ha aBezár gombra kattintok, akkor bezárul az ablak, s ezzel egy időben a lekerdezes.php oldal automatikusan lefrissül?

Köszönettel:

radmin

Ez nem php-s kérdés, de a helyedben ezt a kódot tenném egy js függvénybe és a click eseménykor azt hívnám meg:

window.close();
if (window.opener && !window.opener.closed) {
window.opener.location.reload();
}

ui: mindenki figyelmébe ajánlom, hogy szabványos (x)html kimenetet kreáljon mert lehetnek meglepetések a későbbiekben. Főleg js terén.

letöltöttem ezt a Notepad++-t, de nekem nincsen benne "Formátum" menü. Helyette "Kódolás" van, de ott meg nincsen pötty, vagyis nem látom, hogy milyen formátumban van jelenleg a fájl.

szerk.: bocs, a html-fájlnál nincsen pötty, a php-t betöltve van. (ANSI)

[ Szerkesztve ]

Hát akkor elb×tam a menü nevét, épp nem volt megnyitva a Notepad++, amikor írtam. De ezek szerint sikerült rájönnöd.
Azt, hogy mit kell tenned, már mondtam ("Átalakítás UTF-8 kódolásra BOM nélkül"). Szóval nem értem, mi a problémád.

[ Szerkesztve ]

Sk8erPeter

megpróbáltam átalakítani a html-fájlomat az "ISO-8859-2"-ről "UTF-8 BOM nélkül"-re, de erre minden ékezetes betű elromlott.
pl. a "legmegfelelőbb időpont"-ból ez lett: "legmegfelelĹ�bb idĹ�pont".
ha csak átírom a charset-et utf-8-ra, akkor meg ez: "legmegfelel�bb id�pont".

viszont ha átírom "utf-8"-ra és átalakítva mentem el, akkor jó lesz.
ha a Frontpage-ben írom át a charset-et "utf-8"-ra, ott sima mentés után is jó lesz.

de hogy ne legyen egyszerű az élet: a két jó változat közül a Frontpage-es pár byte-tal nagyobb lesz, mint amit a Notepad++ csinál. ki érti ezt?

pl. a Frontpage-es "©" jelet a Notepad++ átalakítja "&copy;"-ra.

Az "ÁTALAKÍTÁS" kezdetűre mentél? (NE a simára...)
Mellesleg miért érdekel, hogy a fájlod nagyobb-e pár bájttal? Felejtsd már el azt a rakás szar Frontpage-et, nem értem, manapság hogy lehet még ilyen fos programot használni. Ha már fizetős program, akkor pl. Dreamweaver (többek közt).

"pl. a Frontpage-es "©" jelet a Notepad++ átalakítja "&copy;"-ra."
És szerinted a Frontpage-es kódban hogy szerepel?
Nézz utána a HTML-kódoknak ([link]), és akkor nem fog annyira zavarni...

Sk8erPeter

na jó, lassan feladom...

átalakítottam a html-t és a php-t is, de a php által küldött emailben továbbra is totál összevisszaság van.

a php-fájlban szereplő "Tanácsadás" szó helyett "TanĂĄcsadĂĄs". a látogató által beírt üzenetben pedig "őű" helyett "%u0170%u0150".

Egyáltalán beállítottál karakterkódolást a levélküldéshez? Bocs, de pánikolás helyett inkább előbb olvass utána...ha nagyon nem találod a választ, majd akkor ijedj meg, hogy jujj, nem lesz megoldás, mi lesz veled...
Eddig nem közölted, hogy emailnél van (vagy annál is) a probléma.

Cikk:
Levélküldés PHP-ben

Sk8erPeter

a php egy levelet küld egy megadott címre. a php elején szerepel a karakterkódolás:
header('Content-type: text/html; charset=utf-8');

később a levélküldő résznél ezek:
// Instellingen voor verzenden van de mail
$boundary = "--".md5(uniqid("myboundary"));
$priorities = array('Highest', 'High', 'Normal', 'Low', 'Lowest');
$priority = 2;
$charset = "utf-8";
$ctencoding = "8bit";
$mime_vers = "Mime-Version: 1.0\nContent-Type: multipart/alternative;\n boundary=\"".$boundary."\"\n";
$x_mailer = "X-Mailer: PHP\n";

// header voor de website eigenaar
$header_van = $mime_vers.$x_mailer;
$header_van .= "From: ".$reply."\n";
$header_van .= "Reply-To: ".$van."\n";
$header_van .= "Return-Path: <".$van_adres.">\n";
$header_van .= "X-Priority: ".$priority."\nX-MSMail-Priority: ".$priorities[$priority]."\n";

// header voor de invuller van het formulier
$header_aan = $mime_vers.$x_mailer;
$header_aan .= "From: ".$reply."\n";
$header_aan .= "X-Priority: ".$priority."\nX-MSMail-Priority: ".$priorities[$priority]."\n";

// bericht voor de website eigenaar
$message_van ="This is a multi-part message in MIME format.\n\n";
$message_van .= "--".$boundary."\n";
$message_van .= "Content-Type: text/html; charset=".$charset."\n";
$message_van .= "Content-Transfer-Encoding: ".$ctencoding."\n\n";
$message_van .= "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\">\n";
$message_van .= "<html>\n<head>\n<META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset=".$charset."\">\n<style>\n";
$message_van .= "body,p,td {font-family: verdana;font-size:11px;line-height:16px; }\n";
$message_van .= "\n</style>\n</head>\n<body>\n";

// bericht voor de invuller van het formulier
$message_aan = $message_van;

nem tudom, hogy ez mennyit segít a probléma megoldásában.

jelenleg a php-ban szereplő ékezetes szavak rendesen megjelennek a levélben, viszont az üzenetbe beírt karakterek nem.
az üzenetnek azokat a sorait, ahol ékezet van, html-nézetben meg sem jeleníti a levelező (kivéve az "őű", amik helyett a fentebb szereplő kódot írja ki.

a weboldalon vannak még javascript fájlok is - ezeket is át kell alakítani "utf8 bom néklül"-be?

köszi a segítséget!

nekem úgy is jó lenne, ha sima text-formában érkezne meg a levél, nem ragaszkodom a html-formához.

nem biztos, hogy a problémát maguk a fájlok okozzák.

A kódolás általában egy lekérésre adott válaszban kétszer jelenik meg.

1: A http fejlécben
2: magában a http kérérsre érkezett általában html válaszban

Természetesen a kettő lehet eltérő. Ha ez megtörténik a böngészők általában a http fejlécben szereplő értéket tekintik helyénvalónak.

Ellenőrzésképpen ezt tudod tenni:

http://web-sniffer.net

ide beírod a lekérések címét és láthatod hogy milyen adatok jönnek a http fejlécben. A neked fontos a Content-Type, ha abban iso-8859-1 van és a html tartalomban pedig más akkor ott a baj.

Ha ez fordul elő, akkor a php - header függvénnyel tudsz megadni új Content-Type-ot.

a http://web-sniffer.net-en az összes fájlnál ezek az adatok szerepelnek:
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7[CRLF]
Accept-Language: de,en;q=0.7,en-us;q=0.3[CRLF]

függetlenül attól, hogy magában a fájlban ISO-8859-2 vagy UTF-8 van.

ne a HTTP Request Header -t , hanem a HTTP Response Header-t nézd, ami alatta van a táblázatban, a Content-Type általában a legutolsó sora.

függetlenül attól, hogy a php-fájlban milyen charset van megadva, az eredmény mindig ez:

Content-Type: text/html; charset=iso-8859-1

(a Response Header első sorában ez áll: "Status: HTTP/1.1 404 Not Found" - ez nem gond?)

BOCS, rosszat néztem!

Content-Type: text/html; charset=utf-8

ezek szerint ez a része jó?

te tudod, hogy megfelelő-e, ha utf-8 kell mindenhol akkor jó..

akkor ez a lehetőség kilőve.

A másik hibalehetőség, hogy az adatbázisból már rosszul kódolt adatok jönnek ki. Ennek kellene utánajárnod. Viszont ahhoz kellene valami kódrészlet is hogy lássuk.

csak nem sikerül rájönnöm a megoldásra.

ha iso-8859-2-t használok mindenhol (html, php), akkor a php által elküldött levélben minden jó, kivéve az "őű" betűket. (helyettük ez áll: "%u0150%u0170")

ha viszont mindent átállítok utf8-ra, akkor a levél üzenet részében txt-módban kérdőjelek vannak a normál ékezetes betűk helyén (pl. próba --> pr?ba), html-nézetben pedig ezeket a sorokat egyáltalán nem jeleníti meg.
az "őű" betű itt is ugyanolyan kódot kap, viszont ezt html-nézetben is látni.

az oldal így néz ki:
- van egy html fájl, amiben egy javascript szkript bekéri az adatokat (pl. név, üzenet), majd továbbítja az adatokat a php-fájlnak.
<script type="text/javascript" src="js/jquery.ajaxContactForm-1.3.0.js" charset="utf-8"></script>

<script type="text/javascript" charset="utf-8">
$(document).ready(function() {
$('#tanacsadas').ajaxContactForm('functions/send_ajaxcontactform.php', {});
});
</script>

- az adatok bekérése így történik:
<table border="0" cellpadding="0" cellspacing="0" id="tanacsadas">
<tr>
<td><label for="i0">Az Ön neve *</label></td>
<td width="20"></td>
<td><input id="i0" type="text" size="24" name="naam__v" value="" class="input"></td>
</tr>
<tr>
<td><label for="i4">Üzenete, kérése</label></td>
<td width="20"></td>
<td><textarea id="i4" cols="24" rows="8" name="bericht" class="input openair"></textarea></td>
</tr>
<tr>
<td></td>
<td width="20"></td>
<td><input type="submit" name="su" value="Tanácsadást kérek!" class="button"></td>
</tr>
</table>

ez a js-szkript dolgozza fel: jquery.ajaxContactForm-1.3.0.js

lehet, hogy ebben van a hiba???

Ezek alapján azt gondolom a levelezővel lesz a probléma:

próbáld ezt átírni, figyelj a charset-re (utf-8al próbáld):

$subject = 'Birthday Reminders for August';

// message
$message = '
<html>
<head>
<title>Birthday Reminders for August</title>
</head>
<body>
<p>Here are the birthdays upcoming in August!</p>
<table>
<tr>
<th>Person</th><th>Day</th><th>Month</th><th>Year</th>
</tr>
<tr>
<td>Joe</td><td>3rd</td><td>August</td><td>1970</td>
</tr>
<tr>
<td>Sally</td><td>17th</td><td>August</td><td>1973</td>
</tr>
</table>
</body>
</html>
';

// To send HTML mail, the Content-type header must be set
$headers = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";

// Additional headers
$headers .= 'To: Mary <mary@example.com>, Kelly <kelly@example.com>' . "\r\n";
$headers .= 'From: Birthday Reminder <birthday@example.com>' . "\r\n";
$headers .= 'Cc: birthdayarchive@example.com' . "\r\n";
$headers .= 'Bcc: birthdaycheck@example.com' . "\r\n";

// Mail it
mail($to, $subject, $message, $headers);

egyébként innen van.

Na látom még senkinek nem tűnt fel egy apróság, ezért beleszólok én is.
Egy dolog a weboldalad karakterkódolása és egy teljesen más dolog a php programod által elküldött email karakterkódolása. A weboldalad karakterkódolásának tulajdonképpen semmi köze az email küldéséhez.

Ahhoz, hogy egy weboldalról a megfelelő karakterkódolásban kapd meg az adatokat, a következőkre figyelj:
- a weboldalad szövege megfelelő karakterkódolású legyen
- a <head> részben töltsd ki a karakterkódolást
- előfordulhat, hogy a http header-ben is be kell állítsd a karakterkódolást (szerverfüggő)

A levél küldéséhez pedig javaslom, hogy használj valamilyen előre megírt osztályt, mondjuk a phpmailer-t. Ott megadod a karakterkódolást és kész vagy, minden mást elintéz neked az osztály.

Amúgy ha nem akarod szivatni magad, akkor az adatbázisodnál, a honlapodnál és a php szkripted minden eleménél ugyanazt a karakterkódolást használd. (Lehetőleg utf8-at)

a linkelt javascript-fájlban volt egy ilyen sor:
data_arr.push(name+'='+escape(valu));

miután - próba-szerencse alapon - kivettem innen az escape-et, egyből csoda történt, és a php már hibátlanul küldte el a levelet!

illetve: a TheBat! levelezőprogram rendesen tölti be, ha viszont a webmailes Horde-dal (vagy hasonlókkal) nézem, ott totál gáz.

szóval nem biztos, hogy ez a legjobb megoldás...

Ez most lehet, hogy csak számomra tűnik ellentmondásosnak. Azt mondod, hogy az email végső kódolásának, a küldött adatoknak köze nincs a weblap karakterkódolásához, aztán kifejted, hogy mégis (pl. "- a weboldalad szövege megfelelő karakterkódolású legyen - a <head> részben töltsd ki a karakterkódolást. -..."). Vagy csak félreérthető volt a postod (számomra igen).
Szép dolog az előre megírt osztályok használata, de tulajdonképpen jó lenne rábírni, hogy rendesen működjön saját módszerrel is, abból lehet tanulni, ha Te írod meg. Múltkor nálam is volt valami probléma a levélküldésnél bizonyos karakterkódolásoknál, azóta mondjuk még nem volt időm foglalkozni a levélküldözgetésekkel, megoldottam más kódolással. Az előbb leírt megoldás problémájára kellene rájönni, az lenne a legjobb.

Sk8erPeter

Ez most lehet, hogy csak számomra tűnik ellentmondásosnak.
Pedig nem ellentmondásos, csak lehet, nem fogalmaztam elég világosan

A levélküldés és a weboldal karakterkódolása között elvileg nincs kapcsolat. Érted, írhatsz olyan php scriptet, ami semmiféle weboldalt nem gyárt, mégis küldi a levelet.
A jelen esetben viszont a levél tartalma a weboldalon található form-ból jön, na itt már nem mindegy a weboldal kódolása. A böngészők olyan kódolással fogják küldeni az űrlapra felvitt adatokat, amilyen kódolást megadtál a honlapodnál.

Szép dolog az előre megírt osztályok használata, de tulajdonképpen jó lenne rábírni, hogy rendesen működjön saját módszerrel is, abból lehet tanulni, ha Te írod meg.
Ez esetben meg lehet nézni a phpmailer forráskódját, hogy lásd, milyen header-öket állít be a levélhez. Azért nem érdemes vele tökölni, mert a levelezőprogramok eltérően viselkednek, tehát megkíméled magad egy csomó fölösleges problémától. Például van olyan levelezőprogram, ami hibásan jeleníti meg a levél tárgyát, ha az utf8-as kódolású és ékezetes karaktereket is tartalmaz. Lehet tökölni azzal, hogy kitalálod, hogyan kell kódolni az email header-jében a subject sorokat ahhoz, hogy minden levelezőprogramnak jó legyen, csak nem látom értelmét, ugyanis a probléma már meg van oldva, ingyenes, lehet használni, ha érdekel, hogy hogyan működik, akkor ott a kód, meg lehet nézni, stb.

Amúgy meg elég nehézkes dolog a levelezést tesztelni. Van rengeteg levelezőprogram, ott vannak a különféle verziójú outlook-ok, az összes webes levelezőrendszer, senkinek nincs arra ideje, hogy ezeken mind végigzongorázza, hogy vajon jó-e az a levélküldő kód, amit írt. Elég nagy probléma szokott azzal is lenni, ha az ügyfél szépen formázott, weboldal-szerű html levelet szeretne kiküldeni, mert minden egyes levelezőprogramnak vagy weboldalnak megvannak a saját maga hülyeségei.

"A jelen esetben viszont a levél tartalma a weboldalon található form-ból jön, na itt már nem mindegy a weboldal kódolása."
Na ez az, éppen ezért volt ellentmondásos, amit írtál.
Mégpedig ez:
"Na látom még senkinek nem tűnt fel egy apróság, ezért beleszólok én is.
Egy dolog a weboldalad karakterkódolása és egy teljesen más dolog a php programod által elküldött email karakterkódolása. A weboldalad karakterkódolásának tulajdonképpen semmi köze az email küldéséhez."

A többivel kapcsolatban teljesen egyetértek.

Sk8erPeter

na már majdnem tökéletes a válaszlevélküldő. mindent átalakítottam utf-8-ra.
egyedül a levél tárgy sorában, illetve a feladónál szereplő szavaknál hibázik. pl. "Tanácsadás" --> "TanĂĄcsadĂĄs", és "Visszaigazolás" --> "VisszaigazolĂĄs".

ezek a sorok a php-ban szerepelnek, kb. így:
$to_adressen = array(
0 => array('Tanácsadás', 'email@sajatdomain.hu')
);

$reply_onderwerp = 'Visszaigazolás a '.$deWebsite.' weboldalról';

vmi ötlet?

Gyors válasz: levélküldéshez használj phpmailer-t, az megoldja.

Olyan problémát kellene megoldanom, hogy adott időpontonként végrehajtok egy műveletet, ezt hogyan tudom megvalósítani phpben?
Tehát mondjuk naponta mindig éjfélkor vagy valamikor megvizsgálnék valamilyen adatot ami az adatbázisba került és annak megfelelően módosítást eszközölnék a phpval.

ha unixos geprol van szo akkor cron

Nem vagyok egoista, csak uborkagyalu!

Ha 5.1 es mysql vagy újabb van, esetleg lehet tárolt eljárásokat is ütemezni.

Má' nem

Windows, illetve mi is ilyesmiben gondolkozunk, mint ütemező esetleg, nem tudom mennyire jó megoldás!?

Oracle az adatbázis.
Gondolkoztam már triggeren de az nem jó, mert csak aktualizálás esetén fut le, valami hasonló kellene mint egy trigger csak adott időben fusson le.

Akkor nem értem a kérdést sheduled job, ha jól rémlik oracleben így hívják de a oracle.com ebben szerintem igen nagy segítséget tud nyújtani

[ Szerkesztve ]

Má' nem

Akkor a lényeg.

Suliba kell egy projektet készíteni, egy aukciós házra esett a választás.
Ugye vannak licites termékek, amiket a lezárás időpontjában kellene megnézni, hogy elérte e a minimális árat és ha igen, akkor érvényessé tegye a vásárlást, egyébként pedig ne.

Úgy lett kitalálva, hogy minden termék lejárati ideje mondjuk éjfél előtt kicsivel lenne és akkor éjfélkor lenne ez a vizsgálat a lejárt termékekre, hogy eladásra került vagy sem.
Remélem így most már érthetőbb.

Minek ehhez ütemezés? Elég akkor megvizsgálni, hogy lejárt-e, amikor valaki megnézi a licitált árut. Így bármilyen lejárati időt meg tudsz adni neki.

Igen ,de mi van akkor ha senki nem nézi meg a licitált árut?
Nekem anélkül is el kell döntenem ,hogy lejárt e vagy sem.

google első találat, és szépen le is rajzolja hogy csinálj sheduled jobot
http://www.oracle.com/technology/obe/obe10gdb/manage/scheduler/schuser.htm

Má' nem

Nah megpróbálom ez alapján.
Köszi.

addig minek? eláll az ott, nem? csak akkor kell eldöntened, ha hozzá akar férni valaki ahhoz a tételhez. ha nagyobb adatbázisban gondolkodsz, csak feleslegesen terheled a szervert minden éjfélkor, esetlegesen több tíz- vagy százezer tétel átnézésével.

ezt én úgy csinálnám, hogy el sem tárolnám, hogy lejárt-e, hanem minden hozzáféréskor ellenőrizném: if ((pontosidő >= lejáratidő) && (aktuálisár >= minimálár)) { lejárt; } else {nemjártle; }

[ Szerkesztve ]

Aha, és ha mondjuk listázni szeretném a liciteket, akkor minden egyes esetben végigzongorázza a rendszer a több tíz/százezer terméket? A termékek/licitek listázása pedig elég gyakori egy ilyen oldalon. Ennél sokkal jobb az éjféli ütemezett feladat, ami amúgy nem feltétlenül lassú, tekintve hogy nem kell az összes liciten végigmenni, csak amelyik aktív státuszú és éppen lejárt az érvényessége.

Listázáskor így is úgy is végig kell mennie rajta, és tök mindegy, hogy milyen feltételt vizsgál. Azt, hogy lejárt flag van vagy dátum. De végülis nekem tökmindegy, hogy hogy csináljátok, csak segíteni akartam. Ha majd egyszer aukciós házat nyitok, én biztosan nem ütemezéssel fogom megcsinálni.

ha határideje van az aukciónak, akkor érdemes időzített feldolgozást csinálni, és pl. lezárás után egyből mehetnek ki az értesítő mailek a nyerteseknek stb.
az adatbázis meg azért van, hogy 10-100ezer rekordot kezeljen. naponta 1x fut le úgyis.

"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser

Nem hülyeség.
Egyébként elvileg nagy adatbázis lenne, de élesben szerintem nem lesz bevetve csak egy projekt munka suliban, de ha már csinálom, akkor legyen fasza.

Nah igen én is ezen az elven indultam el.
Elvileg pont ezért használjuk az oracle-t is, hogy tudja kezelni a sok rekordot, méghozzá hatékonyan.

az mit jelent, hogy "a session kezelés működjön több szerveres környezetben is"?
3 féle userem van, különböző aloldalakhoz kell hogy joguk legyen.