Valószínûleg mert 16 bites (win 3.1-es) progi. Az egyes
windowsok hajlamosak eltérni, Pl. én is írtam egy
számlázóprogit (X-Raktár II) ez már 9x-en sem megy csak
win2k és XP alatt (meg persze linuxon). Még csak RC1 van
belõle, lehet hogy mire kijön az 1.0 (úgy egy-két hét)
addigra megcsinálom a 9x kompatibilitást (igazából csak a
space-es fájlnevekkel van gond amit a 9x és a normális
operációs rendszerek (linux, win2k, XP) eltérõen kezelnek,
de nem tudom mennyi értelme van még 9x-szel foglalkozni
(amúgy sincs normális fájlrendszer, védelem, stb ami azért
kellene ahhoz hogy üzleti alkalmazást komolyan lehessen
futtatni rajta).

astalavista.com, ott találsz töréseket a demo verzióhoz. legalábbis jobb 5letem nincs.

Sziasztok!
Segítségetek kérném, mert már teljesen feladtam. Van egy progim ami SQLWindow-ba lett írva (16 bites). Szeretném visszafejteni. Sajnos nem boldogulok. Van egy progi (refox) amivel sikerülne, de a neten csak a DEMO verzióját találtam meg. Nagyon jó lenne, ha segíteni tudnátok. A progi forrása APP kiterjesztésű.
Köszönettel....
Ndre

ja. az engem is érdekelne, hogy mi az.

üdvagyé:)

visual php studio?

egyébként lenne egy kérdésem:

Miért van az hogy a számlázóprogramunk csak win9x alatt képes nyomulni pedig database -ben vannak ott is az adatok...
Win xp alatt viszont bár elindul a progi mégsem használható alatta mert mindenféle hibaüzenetet ír ki.
ez miért van?
Hogy lehet kilőni a kompatibilitásból származó hibákat?
Windowson bellül és azon kívül... Pl: Linux vagy iMac?

Aha találtam benne egy database desktop nevü témát valószínünek tartom itt kell elkészíteni az adatbázist.
? legalábbis az alakját meg az összefüzéseket igaz?

Na jó.. Letöltöttem a delphi 7.0 verzióját és a visual PHP studiót.
Természetessen még nagyon bután ülök itt elötte, de ha valaki tudna segíteni, hogy itt mi micsoda és mivel mit lehet csinázni annak nagyon örülnék.
Gondolom ezekkel lehet előhívni egy adatbázisból az adatokat meg minden... de miben csinázzam az adatbázist?
Mert arrol még nem esett szó...
Vagy csak lemaradtam róla?

csaszek:
Vagyis ha jól utánaszámolsz, a Te megoldásod élből 300e Ft pluszkiadás. Csak a "fejlett" technológia miatt. És akkor nem beszéltem a programozó nullbevételes pluszidejéről. Mert bármennyire egyszerű is a PHP és az SQL-lekérdezés, azért utána kell nézni, meg kell tanulni. A Linuxot, a webszervert, az SQL-szervert installálni kell. Ez sem két perc.
Egyébként nem látom be, hogy a hagyományos fejlesztés miért lenne bonyolultabb. A forrásprogramok pedig azért vannak,
A 3+1 hetes fejlesztési idő akkor lehet reális, ha kész specifikációd van, nem túl bonyolult a rendszer, és elsőre bugmentesen megírod. (Sokszor a megbízóval való egy-egy megbeszélésre kap az ember hasonló terminust.) Azért a nagyobb fejlesztések manapság is hónapokig, évekig tartanak. Pedig mindenki szeret a legkényelmesebb, "legmodernebb" fejlesztőeszközzel dolgozni.
Egy igényes webes felület megtervezése, kivitelezése sem megy 1 hét alatt. Hozzátenném, hogy a magyar site-okon olyan ritka az igényesség, mint a fehér holló. Nálunk még mindig két domináns stílus van: az ipari és a "művészi". A legnagyobb forgalmú webhelyek sem kivételek ez alól. Nagyon látszik, hogy a programozói szemlélet dominál. Aki a programozásban tehetséges, nem biztos, hogy vizuálisan is az.
Drabokra szedhetném az érvelésed, de már belefáradtam. A marketing láthatatlanul legyőzi a józan észt. SQL-ben is általában lényegesen gyorsabb programokat tudok írni, mint mások. Nem utasítom el, csak akkor használom, amikor hatékony. Ami pedig a portolhatóságot, a továbbfejlesztés lehetőségét illeti, a problémák teljesen máshol szoktak kezdődni. Magával az adatbázis-szerkezettel. De ez már egy másik történet.
üdv
szergej

En is lattam pure assembly-ben irt adatbaziskezelot, ami
ugy suvitett egy 386-oson mint a szel, es rafert egy floppyra,
de ma valahogy mar biztosan nem hasznalnam. Hogy miert ?
Mert rendkivul nehezkes volt, es csak dos alatt ment.
Egy csomo dolog hianyzott belole, de a feladatat ellatta.
Lehet most ragaszkodni egy platformhoz, egy technologiahoz,
de ha az ember gyorsan es kolcseghatekonyan szeretne fejleszteni,
akkor jo lesz ha szelesebb spektrumban gondolkozik.
Megintcsak nem akarok belemenni egy ertelmetlen
"de az uj sokkal lassabb" vitaba, mivel egyreszt ez fugg
a rendszertol, a programozotol es meg sok egyebtol, masreszt
az uj szolgaltatasok amit ad, plusz a gepek iszonyatos
merteku gyorsulasa ezt abszolut hatterbe szoritja.

Nem elvaras, hogy pl. egy Oracle egy 486-oson fusson ...
Szentsegtores is lenne.
Gondold csak el, hogy a boltban lassan nem kapni 1GHz alatti procit.
Lattam en is rengeteg rossz peldat, es bug-os adatbaziskezelot,
de en a magam reszerol a mostaniakat nem irnam le a jo par evvel
ezelotti tarsaik botlasai miatt. Fokent, hogy hala a mostaniaknak,
sokkal gyorsabban tudok haladni barmilyen fejlesztessel, es
sokkal jobban atlathatoak, modosithatoak, portolhatoak lesznek a rendszerek. De ez mar nagyon masfele vinne a vitat.

Es azt tapasztalatbol mondhatom, hogy ha valami **** van megirva,
akkor azon a nagyobb vas sem segit. Es ne haragudj meg, de azert
egy jol beallitott es optimalizalt sql adatbazis azert ennyivel
nem lassabb barmilyen mas megoldasnal, sot sokszor hala
az uj technologianak meg gyorsabb is.
Bar a robusztussag mindig a sebesseg rovasara megy.

Marketing ? Az elso pont talan, hogy M$ technologiara nem
epitunk szervert. Ez az en szubjektiv velemenyem.
A windows jo jatszani, szoveget szerkeszteni, zenet hallgatni, de
nem valo szerverekbe. Ezert megkovezhetnek, de igy gondolom.
A kerdezonek nyilvanvaloan van megrendeloje, mert gondolom magatol
nem vagna vakon ilyenbe. Mi kell ? Egy tajvani csoda masina
ugy 100-150-ezerert (minel gyorsabb vinyo(20-40giga), vagy 512mega ram
es 2Gh koruli proci) Ezzel mar tobb ezres ugyfelszamu
adatbazis is rohogve kezelheto, es az ocsemnek erosebb
gepe van mar otthon.
Es meg mi kell?
Linux , egy postgres, apache+PHP.
Nem kell X,nem kell a sok soder sz*r, csak ssh az adminisztraciohoz es kesz.
Ez 0 Forint.
+ket,harom het a fejlesztesre. Ha igenyes kulalakot szeretne
akkor meg egy het. (Majd ekkor latja csak be a kerdezo, hogy
milyen iszonyat gyorsan tud haladni, hala az SQL-nek
es a rohogve megtanulhato PHP-nek.)
plusz kell egy fix ip-s stabil kapcsolat. Na erre most
nem mernek arakat mondani...
Idovel erdemes befektetni egy igazi szerverbe.
(pl. ibm,compaq ups-el,raid-el,stb...)
Ha ezt ki tudja fektetni a termekkatalogussaval, akkor
fizetek mindenkinek egy uveg sort. )

csaszek: Ezért írtam, hogy a konkrét feladat ismerete nélkül nehéz állást foglalni a megoldás mikéntjében. Nekem konkrét tapasztalataim vannak a közepes teljesítményű SQL-szerverek tekintetében, és nem túl jók a tapasztalataim. Indexelni természetesen én is megtanultam, de ez nem változtat azon, hogy az SQL-szerverek erőforrás-igénye, a háttár-feladatok időigénye nem elhanyagolható.
Nyilvánvalóan a kérdező olcsó megoldást szeretne, különben nem állna neki saját maga a programozásnak. Pár százezerért én is megírom Neki csillivilli SQL-es, webfelületes csodává. Persze rákölthet még pár százezret a webszerverre és évi egy-kétszázezret az üzemeltetésre. Szerinted ez a célja? Ha annyira értene a lekérdezés-optimalizáláshoz, az SQL rejtelmeihez, nyilvánvalóan nem tenne fel olyan kérdéseket, amelyeket feltett. Ezért tettem fel a specifikációhoz elengedhetetlen, kezdeti kérdéseim.
Azért elmondanám, hogy annak idején írtam egy elég bonyolult "entitásokat" kezelő szoftvert. Fapadosan, Clipperben. Időszakosan nyomtatványokat kellett előallítania. Ez még a 33 MHz-es PC-k korában volt. Több ezer egyedi jelentést. Kb. 15-20 perc alatt végzett a feladattal egy gépen futtatva az összes feladatot.
Azután áttették SQL-re, mikor eljöttem a cégről. A szoftvercégeknél ugyanis nem a jó programozó a lényeg, hanem a jó üzletkötő. Engem nem tudtak rávenni a "jóra", de amikor elmentem, a cégvezetést igen. Ugyanannak a terméknek az előállítási ideje - a teljes géppark-csere és a 2-300 MHz körüli gépek, a mérgdrága hálózati adatbázis technológia ellenére - megugrott 8-12 órára. Adatbázis kracht esetén a rengeteg biztonsági SQL funkció ellenére egy teljes munkanap kiesett 8-10 dolgozó számára.
Aztán kitalálták a Windowos felület szükségességét. A hálózati- és az adatbázis-szerver most egyenként 1.5 GHz-es. A feldolgozást végző gépek fél gigahertz körül ketyegnek. Most négy gépnek tart 8-12 óráig a feladat. A sok hókuszpokusz ellenére már több olyan adatvesztést produkált a rendszer, amelyet a mentésekből sem lehetett maradéktalanul helyreállítani.
Most akarják az egész cuccost papírról átteni a webre.)) Hát, hadd ne füzzek hozzá kommentárt...
(Mellesleg az ország legelismertebb, multinacionális cégek referenciáival rendelkező adatbázis-programozói végezték a legutóbbi fejlesztést. Tehát nem lehet mondani, hogy nem értenek hozzá. Bár mindig vannak, akik úgy gondolják, hogy ők jobban...)
Ezek után felteszem a kérdést: Tényleg a korral halad az, aki a windows-os, SQL-szerveres, webszerveres megoldásokat választja, vagy megeszi a marketingdumát, pénzét kiszórva az ablakon???
De ha folytatni akarjuk az off-vitánk, szerintem nyissunk új topic-ot.
üdv
szergej

Sziasztok !

A preciz es reszletes rendszertervezes nelkulozhetetlensegeben
teljesen egyetertek Szergej kollegaval, am az SQL kihagyasaval
abszolut nem. Nem szeretnek itt felesleges vitat nyitni a
kerdesben, mert ez igencsak izmos tema, de nehany dolgon erdemes
elgondolkozni:
- ha a tema kinovi magat, akkor kezelhetetlenne valhat
fejlesztoi es adatbazis szinten egyarant, ha nincs
egy ilyen egysegesitett lekerdezesi mod.
- Jo, hogy most optimalizaljuk egy gepre, oprendszerre vagy
adatkezelesi modra, de mi van ha valtoznak a parameterek ?
Pl. Atallnatok valami komolyabb adattarolasi szisztemara ?
Normal esetben meg a programba sem kell tulsagosan belenyulni,
ha az ember szabalyos SQL utasitasokat hasznal.
Pl. Postgres -> Oracle valtas
- Az SQL-es adatbaziskezelok megvalositanak egy csomo olyan dolgot,
amit mas megoldasok nem biztos. Pl. naplozas-visszaallitas,
konkurenciavezerles, optimalizalt lekerdezesfeldolgozo, indexeles..
- Az uj adatbaziskezeloknek igen nagy a tudasuk. Mostanra lenyegeben
a felhasznaloi interfesznek egyre kevesebb munkaja van.
Az adatbazis rengeteg dolgot elvegez helyette, es legtobbszor
mar csak pl. megjelenitesi, beviteli-validalasi feladatokat lat el.
(nagyon hatekony belso fuggvenyek irhatok az adatbazisokban)
- Es nem utolso sorban mostmar eleg gyorsak is. Megfelelo
indexelessel es tabla struktura kialakitassal tobb tiz-szazezres
adatlekerdezesek is megfelelo ido alatt lefutnak. Persze ha
az ember jartas az sql-ben, es gyors lekerdezest ir.
Mert indexeles nelkuli, izombol megirt sql-select akar
20x-40x-szer is lassabb lehet egy jol atgondolt tarsanal.
Es a vegeredmeny ugyanaz.

gye:
Most is éppen egy adatbázis alapú rendszer lekérdezésének eredményét olvasod. Kellett hozzá valamit telepítened?:-)
3:
Bármennyire "fázol" tőle, a program- és adatbázis-specifikációt csak akkor úszod meg, ha vállalod, hogy háromszor annyit dolgozol, mint amennyi egy tisztességes specifikáció elkészülte után szükséges.
Csak néhány kérdést, észrevételt írok az eddig elhangzottak alapján, mert túl kevés információt adtál eddig ahhoz, hogy komoly szakmai véleményt mondjon az ember.
1. A felhasználói oldalon is szükséges termékadat-bevitel?
2. Szét lehet-e választani a felhasználói és a termékforgalmazói-, adatbeviteli oldalt külön adatbázisokra?
3. Hány felhasználóra számítasz napi szinten?
4. Egy felhasználó várhatóan hány lekérdezést indít?
5. A lekérdezésnek átlagosan hány rekord fog megfelelni?
6. A termékek sokféle tulajdonsággal rendelkezhetnek, vagy jól behatárolhatóak és kapcsolt adatbázisban tárolhatóak a jellemzőik?
7. Milyen gyakran kell frissülnie a webes adatbázisnak? Adatbevitel, módosítás után azonnal? Naponta? Hetente?
8. Legyen-e lehetőség szabadszavas keresésre?
9. Legyenek-e termék-kategóriák, többszintű termék-hierarchia?
10. A termékekhez tartoznak-e alkatrészek, részegységek, termék-kiegészítők?
11. Legyen-e lehetőség automatikusan a hasonló termékek megjelenítésére?
(Ezekre a kérdésekre kellene tudnod válaszolni ahhoz, hogy eldönthesd, kell-e saját webszerver, vagy elég egy MySql+PHP-s saját domain.)
12. A felhasználóknak személyes bejelentkezésre legyen lehetőségük?
13. Az adatbázis relációs legyen?
14. Készüljön-e külön felhasználói adatbázis, amely a "bizalmas" adatokat nem tartalmazza?
15. A számlázóprogram adatai nem használhatók fel az adatbázis feltöltésére?
16. Ha gyors lekérdezést szeretnél, az SQL-t felejtsd el. Tudom, ezzel az adatbázisprogramozók többsége nem ért egyet, csak hát: a tények. Az SQL-nek ugyanis nincs agya, gondolkodási képessége. Neked vannak ezek.
17. Szintén a gyors lekérdezést és megjelenítést szolgálja az, ha készítesz külön lekérdező táblát, táblákat. Egyszerűbb ezeket egyszer legenerálnod, mint felhasználói lekérdezésenként SQL-eztetni a szerver oldalt. Persze ez a megoldás akkor hatékony, ha napi egy felhasználó-oldali frissítésnél nincs többre szükség, vagy ha az adatbevitel lekezeli a lekérdezőtábla-frissítést is.
18. A lényeg az, hogy kell-e szerver-oldali adatbevitel, és le kell-e kezelni relációs táblákat. Ez ugyanis az adat-integritás miatt elég kemény feladat, főleg ha nem akarsz saját webszervert méregdrágán üzemeltetni.
19. A flash-hez sajnos telepíteni kell. A javahoz is persze a JVM-et, de azon a legtöbb felhasználó hamar túlesik. A flash különböző verziói ellenben állandóan bekavarnak.
20. Az adatmegjelenítésre a legegyszerűbb a html-es megoldás. Nem látom be, hogy miért kellene java és főleg flash.
Végül: Amikor így látatlanban ír, mindig az az ember érzése, hogy jó eséllyel leír egy-két ökörséget. Ezért - hogy ne a viták, hanem a megoldások felé mozduljunk el - kihagytam jónéhány kérdést és még több észrevételt. Amikkel Neked persze majd szembesülnöd kell.Mentségemre szóljon, hogy nagyon információhiányos ezidáig a topic. Sok sikert a fejlesztéshez!
üdv
szzergej

sziasztok!
Csak megkérdezném, hogy az adatbázis alapú rendszer, és a "ne kelljen telepíteni" hogy férnek össze egymással? Vagy text alapú lenne az adatbázis?

üdvagyé:)

Hát köszönöm az eddigi segítségeteket!
A hozzászólásokat még mindig szivessen várom.

A leírtak után valószínüleg a Java vagy a Flash mellett maradok.
Ezért a következő kérdésem az lenne, hogy mi a különbség a kettő között?
Még egyiket sem használtam, és érdekelne szerintetek melyiknek áljak neki így ismeretlenbe, melyikkel mit lehet csinálni ebben a témában vagy akármi másban.
És miben készítsem el az adatbázist?

Ugye a nagy kerdes, hogy CD-n terjeszted, vagy online webes
feluleten hozzaferheto a cucc.
Megmondom oszinten nem sok erv szol a CD-s terjesztes
mellett.
Ha a webes megoldast valaasztod, technologiak tomkelege
kozul valaszthatsz (webszerverek, ingyenes szerveroldali
script megoldasok), a platformfuggetlen, telepitesmentes
megtekintes adott, az adatbazist akarmikor frissitheted: a
user mindig a legujabb infokat latja.

Szia!

> A cucc cd-n való terjesztésénél az automatikus indítás már egyszeű azthiszem...
Annyiban nem, hogy Linux alatt általában nem működik (egy exe-t
felesleges is lenne elindítani...).

> A megtekintéshez ne kelljen semmit telepíteni, és lehetőleg minden platformon mennie kéne! Win all, linux, stb... ha jól tudom többek között a html téma lenne a király.
A HTML abból a szempontból nem jó, hogy nem fogsz tudni benne keresni,
nem iteraktív megoldás. Erre egy keresztplatformos megoldás lehet, ha a
keresőd JAVA-ban, vagy Flash-ben, extrém esetben esetleg Javascript-ben
van írva. A keresés eredménye már lehet sima HTML file, amit feldob
valamelyik megoldás.

> szóval durva! a számlázóprogram feltöltése képek nélkül 3hónap volt amikor csináltam, de ennél valamivel gyorsabb adatbevitelnek is örülnék ebben az esetben, ezért is fontos a sebesség minden szempontból nézve.
Magát a feltöltést úgy végzed, ahogy akarod. Én egy adatbázisba
pakolnám, és írnék rá valamilyen programot, ami átláthatóvá és
egyszerűvé teszi ezt a folyamatot.

Ezután kell majd egy program, ami az adatbázisból felépíti a HTML
file-okat, a bennük levő linkeket egymásra, stb. és lementi a kereséshez
szükséges információkat, indexeket a megfelelő megoldás (Flash, Java,
Javascript) számára értelmezhető formátumban.

A legjobb megoldásnak különben a JAVA tűnik, de Flash-ből és
Javascript-ből is hozzá lehet férni helyi file-okhoz, csak utána kell
járni (Javascript esetén nem tudom, mennyire szabványos a dolog,
valószínűleg nem az, tehát nem IE-vel, Linux alatt nem működne).

Üdv,
András

A katalógus mintegy 10-15ezer terméket tartalmazna, amelyhez mintegy 6-8ezer fénykép tartozna mire a katalógus elkészülne. Tartalmaznia kéne a termékek minden igényt kielégítő információját és többszintű hozzáféréssel a termékek árait is.

Fontos lenne a sebesség, az egyszerű tételkimásolás, bővítés és módosítási lehetőség , a lehető legegyszerűbb adatbeviteli forma.
Szükség lenne vonalkód használatra is.

A cucc cd-n való terjesztésénél az automatikus indítás már egyszeű azthiszem...
A megtekintéshez ne kelljen semmit telepíteni, és lehetőleg minden platformon mennie kéne! Win all, linux, stb... ha jól tudom többek között a html téma lenne a király.

szóval durva! a számlázóprogram feltöltése képek nélkül 3hónap volt amikor csináltam, de ennél valamivel gyorsabb adatbevitelnek is örülnék ebben az esetben, ezért is fontos a sebesség minden szempontból nézve.

Szia!

> Egy fényképes termékkatalógust kellene készítenem, de fogalmam sincs miként kezdjek hozzá... Ti mit ajánlanátok?
> Fontos lenne az egyszerü adatbevitel, a módosítás, a keresés és a telepítés nélküli megtekintés más gépeken!

Fejtsd ki bővebben légyszi! Milyen platformokon kell működnie a
dolognak? Mit értesz az alatt, hogy telepítés nélküli megtekintés?

1) web alapú
2) CD alapú, valamilyen programmal pl. Delphiben
3) CD alapú, Flash megoldás
4) CD alapú, JAVA megoldás

etc.

Mekkora a termékkatalógusod, szükséges komoly adatbázis és a nagyon
gyors találat a kereséshez, vagy pedig ha gondolkodik rajta pár
másodpercet, akkor az nem gond?

Van sok megoldás...

Üdv,
András

Szerintem neked valami webes megoldásra van szükséged.
A "telepítés nélküli megtekintés más gépeken" máshogyan
nemigen fog működni.

Ehez kell egy webszerver (mondjuk Apache), kell egy adatbázis
szerver (MySQL, Postgres, Interbase, Oracle, DB2 vagy akármi) és
valami programnyelv amiben megírod magát az alkalmazást
(ez általában Java vagy PHP és persze a HTML).

Ezzel aztán lehet variálni. Például eldöntheted, hogy a termékek
feltöltése is weben keresztül történjen, vagy jó hozzá valami
sima desktop alkalmazás is. Hisz azt gondolom nem mindenki
végezheti el. Ez utóbbi megoldás sok esetben egyszerűbb és
gyorsabb.

Kell-e hozzá valami jogosultsági rendszert építeni, ha igen, akkor
az milyen szintű legyen.

A termékkatalógus képeit a fájlrendszerben tárolod, vagy az
adatbázisban.

stb. stb.

Miután ezeked eldöntötted, (és ezeket nem árt előre le is írni,
hogy hogyan fog kinézni). Akkor megalkotod hozzá az adatbázist, és
csak ez után érdemes bármiféle kódolásba fogni.

Matti

Hy!

Egy fényképes termékkatalógust kellene készítenem, de fogalmam sincs miként kezdjek hozzá... Ti mit ajánlanátok?
Fontos lenne az egyszerü adatbevitel, a módosítás, a keresés és a telepítés nélküli megtekintés más gépeken!

Köszi!