Xbase++

Igen foglalkoztunk már vele.
Az xb2net-el minden gond nélkül megoldható, ez tud mindeféle web alapú titkosított kódolást, ssl-t stb..

Sziasztok!


Endem az érdekelne, hogy xBase és Express++ alatt foglalkozott már valaki

a NAV számla küldéssel ? Tudja valaki, hogy az XB2NET -el megoldható?

A html5/js úgy 5 év múlva lesz valóban elterjedt. Addig a különféle böngészők különféle subsetjeit fogják megvalósítani, és kb. 5x akkora szívást jelent majd a fejlesztőknek mint a html4.

És utána is kliens-only technológia lesz, azaz a html/js mellett még megtanulhatsz még valamit - vagy javát vagy .NET-et, mert kell valami ami az adatokat és az üzleti logikát adja a html és a javascript alá. Vagy taknyolhatsz PHP-ben, amit mondjuk könnyű megtanulni, de azzal jár hogy úgy 1-2 évente tanulhatsz új frameworköket, és ha melót vagy dolgozót keresel akkor jó eséllyel belefutsz abba hogy az épp használt frameworköt még nem is látta a delkivens.

Szerintem nem kell feltétlenül a trendetket követni, ha nem hajt a tatár. Nálunk Progress-ben is kiválóan elvisznek 1-2 projectet a mai napig is. Ha nagyon trendi akarsz lenni, akkor javascript és html5. A windows8 felülete már erre épül. Mire megtanulod már a .NET is elavult lesz.

Egy kétórás próbában egy kicsi tesztprogramot lefordítottam vele.
Ment, működött.

Valós gyakorlati tapasztalataim nincsenek.
Volt egy elfogadható (Clipper után!) IDE is hozzá.

Bocsi, nem nézem naponta ezt a postafiókom, sem a topicot mostanában! Elnézést!!!

Megfogadtam LC tanácsát, beszereztem kb. 30 cm szakirodalmat, súlyra is van 4-5 kg. Azt nem mondom, hogy tanulom, bár belekezdtem (SQL elsősorban), de azt igen, hogy az Xbase++ folytatásáról letettem. Rendszerterv-készítéssel foglalkozom, amikor csak tehetem. Utána pedig C# és .NET lesz műsoron. Ha kell, tanfolyamra is beiratkozom majd.

Nézz körbe a Clipper kontra XP topicban.

Erről a Clipper klónról mit tudtok?:
Harbour
Régi Clipper-es forráshoz jó ez a free rendszer?
Valaki használta már?

Most találtam meg az Xbase++ topikot. Örülök, hogy van valaki rajtam kívűl, aki az Alaska Xbase++ szal foglalkozik.
Kérdezném, hogy mire jutottál?

Nagyon köszönöm a javaslatot, az összefoglalót!!!

Mindenképp megbízhatóság (bár ez - gondolom - teljesül mindre), jó teljesítmény, linux és win is, valamint hosszú távúnak látszó free státusz lenne jó. Ez a szelekció jószerével a Postgresql-t hozza ki, ha jól látom. Én még nem vagyok olyan megbízható, mint egy SQL-szerver, ezért megerősítést kérnék :)

Igen, különösen ha Visual Studio Express-t használsz.

Ha nem, akkor érdemes eldönteni mit akarsz, mindennek megvan az előnye és a hátránya. Én amiket próbáltam, azokból ezt szűrtem le. Persze szigorúan szvsz:

MS-SQL
+ Jó teljesítmény
+ Jó támogatottság még az VS Express verziókban is
- Nagy méret telepítéskor
- Ha nagyobb teljesítés kell mint amit az SQL Express enged akkor elég drága
- Csak windowson létezik
Firebird
+ Kicsi méret
+ Beágyazottként is fut (azaz 1 usernek nem kell telepítő)
+ Multiplatform
+ Elég kellemes ADO.NET provider
- Nem túl jó nyelv a tárolt eljárások kezelésére
- Nincs natív GUID típus
- Picit butácska volt a tárolt eljárások szintaktikája, legalábbis amikor utoljára néztem.
- Az Express verziók nem támogatják
- Legalábbis az általam ismert 2.x-es verzióknak azért voltak
teljesítménybeli problémái. Mondjuk a DBF-nél így is több tucat fényévvel jobb
- Normális adatbázis managert eddig még csak fizetősben láttam hozzá. Vannak opensource cuccok, mint Pl. a flamerobin, de elég büntetősek egy SQL Management Studio után.

Postgresql
+ Elég nagy teljesítmény, legalábbis jókat mondanak róla
+ Elég okos SQL szintaxis
* Elég rég használtam, így többet nem tudok mondani róla,
Pl. hogy mennyire jó az ADO.NET/EF providere

MySQL
+ Sokan használják
+ A legtöbb linuxban eleve benne van.
- Elég zavaros licensz, elvben csak a fizetőset teheted a
szoftvered mellé.
* Ezt eddig csak PHP-s dolgokban használtam, így Pl. tárolt eljárást nem írtam hozzá, és csak a PHPMySQL felületen keresztül adminisztráltam.

SQLite
+ Nem kell szerver a telepítéséhez
+ Jó .NET provider
+ Egyszerű tárolt eljárást írni hozzá .NET-ben.
- Csak beágyazottként az igazi
- Sok adattal elég lassú

MS SQL Server 2008 Express.

Ez Free és amire eddig használtad az XBase-t arra ez több mint megfelelő lesz.

SQL Server Editions Overview

W.

Sziasztok!

Úgy gondoltam, laikusságom bizonyításával nem szükségszerű más témát terhelni: jobb, ha itt igazolom újra és újra :)

Nos, beszereztem a több kilónyi szakirodalmat C#, .NET és SQL témakörben (már csak olvasni kell megtanulni :), de még nem tudom, hogy melyik SQL-szervert válasszam. Free lenne jó: Firebird, Postgre, ... Mit javasoltok? Ha többet is ismer valaki testközelből, írna egy-két mondatot előnyről-hátrányról?

Nem győzöm hangsúlyozni: örülök, hogy idekeveredtem, hatásotokra teljes fordulatot vett a korábbi elképzelésem!

Egy nagy baja van, hogy szerényen dokumentált ... pedig - amennyire - látom, van egy rakás lehetőség benne ... Sajnos nem bírom még a delphi minden csínját-bínját annyira, hogy minden részét értsem ... :(

C#-hoz kerestem.

Ez a Delphis jó kompinak tűnik, majd ránézek

Hát .... azt nem mondtad, h milyen nyelvhez kellene .....

A delphihez én a Vlad Karpov féle cuccot használom

Nem, én az sql-t akkor használom, amikor az egész tábla végigolvasása nem gond (nagy eredményhalmaz vagy az index csak részben segítene illetve összetettebb feltételrendszer), de gyakran léteznek direkt rápozícionálások (pl. adott kulcsú rekord elérése), ami dbf-ek esetén végigolvasás helyett index mentén kereséssel hatékony (ahogy persze sql adatbázis kezelők is csinálják, de itt nincs olyan).

Tipikus régi dbf tábla elérés, egyszerű rekord manageres használat.
Ha lesz energiám lehet hogy a c++ kódot átírom c#-ra, már csak a kihívás miatt is. Nagyon elegáns kód c++ alatt. [google: botstein+dbf]

Tudom van komplett fizetős megoldás (pl CodeBase), de ez igazán csak egy mellékszál, ha néha régi adathoz kell visszanyúlni.

Sajnos, én nem tudok segíteni.

Ha jól értem, olyan beszerkeszthető free könyvtárat keresel, amellyel NTX-szel indexelt DBF-eket SQL utasításokon keresztül tudnál olvasni/karbantartani.

Mindenesetre ha tud valaki egy jó free libraryt Clipper filek olvasásához (ne adj isten íráshoz is), akkor megköszönném az infót.

DBF-hez még csak-csak van, de NTX-es olvasáshoz nem láttam.

[Szerencsére nekem már C++Builder alá van portolva rendszerem, és ott van jó DBF+NTX olvasó és persze adott az SQL alapú pure DBF olvasás/írás]
A régi rendszerekkel szükséges a kapcsolattartás és nagy dbf táblák esetén elfér az ntx használat is

A helyzet számomra a következő. Úgy becsülöm, 2 éve minimum van a Clipperes rendszeremnek, de inkább több. Komoly sürgetés nincs, pár érdeklődés (hogy lesz-e majd windows-os) viszont igen. De olyanok is vannak, akik félnek a win-estől. Jelenleg 64 bites W7 alatt is boldogulok a DOSBOX felhasználásával, teljes képernyővel is. Ami viszont tetézi a dolgot: eleve nem volt cél számomra átvinni a Clipper-kódot még Xbase++ alá se. Fejlesztő eszköztől függetlenül is gyökeresen újra szeretném írni az egészet, beleötvözve az eddig felgyűlt tapasztalataimat. Tehát: most párhuzamosan egy új rendszer tervezése, valamint tanulás. Csekélység egy favágó programozónak... :)

Örülök, hogy Xbase++-os is megjelent itt, még ha én most távolodom is. Ezt a Vulcan.NET-et megnézem, de szerintem nem szabad nagyon sokat vacillálnom. Az LC által felsorolt 1-3-tól nem idegenkedem, még ha a gondolkodásom tényleges átállítása több éves folyamat is lesz várhatóan, előre tudom. És hát figyelmeztettetek is erre többszörösen.

Amúgy meg vegyék birtokba bátran ezt a topic-ot az Xbase++-osok! Legfeljebb néha átcsap abba, ami eddig jellemezte: Xbase++ kontra .NET. De az is Xbase++.

Hmmmmmmmmmmmmmmm .... érdekes ........


.... csak az a fránya angol ....

Ez már az ő döntése. Az biztos, hogy a leggyorsabb eredményt így éri el, és folyamatosan állhat át a Clipperes logikáról, miközben rendszere már Windows alatt használható.

Mondjuk szerintem is ez a legnormálisabb megoldás ha már valaki mindenáron ragaszkodik a Clipperhez. A gond az, hogy maga a Clipperes program sem fog soha .NET-esként funkcionálni, mivel alapvetően a .NET-es progi és a Clipperes progi gondolkodásmódja közt van legalább 2, de inkább 3 generáció különbség.

1. Kliens-szerver felépítés, SQL, esetleg tárolt eljárások vs dbf.
2. Objektum-orientált tervezés/felépítés.
3. Üzleti logika és GUI leválasztása, esetleg ORM használata.

Ha egy hintóba szerelsz egy 600 lóerős turbófeltöltős benzinmotort, attól az még nem lesz sportkocsi.

A napokban találtam rá egy fejlesztőrendszerre, illetve egy ráépülő rendszerre, ami a Te esetedben abszolút megoldás lehet.

Magyarországon nem ismert, legalábbis egy magyar link sincs rá.

Ez a Vulcan.NET

Weboldaluk: www.govulcan.net

Én sem jártam még alaposabban utána, de ez állítólag egy .NET-re épülő rendszer, azaz fejleszthetsz Visual Studio-ban, akár a 2010-esben (most adták ki hozzá a frissítést), míg a Vulcan.NET pedig adja a Clipper kód fogadását és a DBF használatát.

Szerintem ezzel a legkönnyebben tudnád hamar kiszolgálni az ügyfeleidet és a kódodat folyamatosan válthatnád .NET irányába. Nem gányolva, mert annak valóban nincs értelme.

Gondolom, a grafikus felületet itt mindenképpen meg kell írnod, de a lényegi kódrészek és a DBF kezelés egyelőre maradhatnának. Így nagyon hamar "átfordulhatna" a rendszered, később SQL-re átfordítva az egészet.

A Vulcan.NET elvileg a Visual Object rendszereket egy az egyben .NET alá tudja átfordítani. Mivel a VO a CA terméke, ahogy a Clipper is, ezért a Clipper "módit" egy az egyben kezelheti. Demó is letölthető.

Nekem sajnos ez nem jó (xBase++-t nem fordítja át a sajátos objektumok stb. miatt), de Te még dönthetsz így is. Lehet, hogy ez lenne egy megoldás számodra a viszonylag gyors produktum elérése és a későbbi folyamatos fejlődés céljából.

Teljesen igazad van, és valószínűleg jobban tettem volna én is, ha nem az xBase++-t választom, hanem .NET-et.

Attól függ. A clipperes kódot nekiállhatsz gányolni, de soha nem lesz az igazi, másrészt ahhoz hogy kicsit is hasonlítson a dolog egy működő windowsos programhoz valószínűleg szintén bele kell tenni egy rakás melót. És soha nem lesz versenyképes az eleve erre tervezett eszközökkel. Egy újabb feladatot megoldani egy .NET/C#/Linq to SQL vagy EF segítségével sokkal-sokkal rövidebb idő mint Clipperrel - még ha a két kód minőségét nem is számoljuk.

Én a Kylixos kódomat dobtam ki (ahelyett hogy Delphire portoltam volna - és nem bántam meg, a 4 év ellenére sem). Mert most egy olyan rendszerem van, ami már tényleg többé-kevésbé normálisan össze van rakva. Persze nem mondom, hogy nincs pár olyan dolog amit ma másképp csinálnék (mert amikor a fejlesztést elkezdtem még nem volt Pl. használható ORM .NET alá, sőt még Linq sem) de ezzel együtt így is sokkal-sokkal vállalhatóbb a rendszer mint ha a Kylixost kezdtem volna el portolgatni.

Még 1 dolog. A legtöbb, amire szükséged lesz, az nem a meló...

Hanem a kitartás.

Az utolsó csepp után a pohár újra és újra meg fog telni.

Ez nem elkeserítés, hanem tapasztalat és bizonyos fokú felkészítés, akármit is választasz.

A fa mérete pedig hasonlít az Avatar hatalmas fájára (amit lerombolnak a földiek)

A .NET a vadászgép, az xBase++ pedig a balta (a hasonlat LC kedvéért van). Viszont mennyivel "drágább" a vadászgép (több munka van vele), mint a balta (Clipperről xBase-re átállni)?

Azért mégiscsak jobb megoldás - ha már "kényszerből" váltott xBase-re - mint a semmi. Gondolom előre konfigurált és sok esetben nem a leghatékonyabb beállítással futtatják le a megfelelő SQL parancsot.

Viszont kritikus esetekben folyamatos lehet az átállás a "tiszta" SQL parancsokra.

Én nem tudok magyar fórumról. Vannak oldalak, de az édeskevés, nekem is mindent magamnak kellett megtapasztalni.

Ha jól tudsz angolul, az jól jön, mert magyar doksi sincs.

LC-nek 4 év volt 600k sor. A Tiéd is minimum 100k sor lehet, vagy több. Egy része generálható, de mindenképp embertelen meló lesz vele.

Ha esetleg mégis az xBase++-t választod, és kérdéseid vannak, szívesen segítek, privátban is üzenhetsz.

Ha viszont valóban jót akarsz csinálni, válts korszerű eszközre, de iszonyat sok munkád lesz vele. Az objektumorientáltság egy más szemlélet, de ez csak egy dolog. Minden tekintetben átállás.

Úgy 4 év. De ez alatt nem csak ezt csináltam, viszont ebben benne vannak a különféle kódgenerátorok által produkált sorok is - igaz, ahhoz Pl. a formok felületét is meg kellett tervezni.