úristen, a linux coderek mindig meg tudnak lepni. Valaki képes volt ms access odbc drivert barkácsolni???
Mondjuk a cégünknél láttam olyan linux guru-t, aki magától írt drivert a megvásárolt faxcenterhez. Igaz az óradíja alapján annyit fizettünk érte, mintha vettünk volna egy elve rendes linux driverrel szállított faxcentert
Én kérek elnézést!
Már csak annyi a gond, hogy mivel többségében ékezetes táblaneveim vannak, ezért valószínűleg a karakterkódolás problémái miatt nem tudom elérni ezeket a táblákat.
Erre keresek valamilyen megoldást 
Ekezetes tablanev? hova jutott ez a vilag...
kedvencem a német "kollégák" 'ä' és 'ß' karakterekkel kezdődő táblái...
több mint 10 éves a rendszer, én csak örököltem.
Ez egy access adatbázis, és amikor létrejött kb az volt a cél, hogy valahogyan eltároljon némi információt...
Most meg adott a probléma, ezt kellene megoldani.
10 évvel ezelőtt sem értem, minek írtak ékezetet a táblanevekbe. 
(Mondjuk semmilyen kódba nem szabad ékezetet tenni, legfeljebb kommentbe.)
Nem tudod átszabni a jelenlegi adatbázis-struktúrát? Mindenhol lecserélni az ékezetes táblaneveket is (gondolom ehhez tartozik valami alkalmazás, ott is átírni), plusz Access helyett valami értelmesebb adatbázist alkalmazni. Ehhez nem is kell átírni a teljes alkalmazást, ami nyilván nagyon időigényes, csak legalább ezeket kellene lecserélni, ez akár max. pár óra alatt is kivitelezhető lenne.
Sk8erPeter
az a baj, hogy jelenleg van egy windows-os gépen egy office alkalmazás, amit fene tudja miben programoztak, ott lehet elérni ezt az access adatbázist, és párhuzamosan kellene futnia az én alkalmazásomnak, majd utána lehetne a jelenlegit lekapcvsolni, de én is hajlok abba az irányba, hogy ne átállás legyen, hanem csere.
"párhuzamosan kellene futnia az én alkalmazásomnak" - ezek szerint a linux-on futó PHP-s részt te csináltad. mdb mellé, linux-os PHP, meg valaki által házilag gányolt spanyol/olasz/portugál mdb odbc driver. Gratulálok 
A kókányolás mintapéldája. Ha van rá lehetőség tényleg dobjátok ki az egész hóbelevancot, és csináljátok meg rendesen, konzisztensen.
Én kérek elnézést!
kicsit arrogánsnak érzem a stíludod.
Tudod az dobja az első követ aki még nem tévedett.
Ha jól emlékszem pár napja még meg voltál győződve arról, hogy ubuntus környezetben mdb-t nem lehet elérni. Aztán nekem mégis sikerült, ráadásul amit írtál az csak annyiban "igaz", hogy olasz blogon találtam a csomaghoz helyes leírást, de maga a csomag nem "házi olasz tákolmány", ez egy linux csomag, amit lehet húzni. Ha elolvastad volna a linket, akkor tudnád.
Ha meg nem érdekel annyira, akkor meg minek okoskodsz. És nem attól lesz valami gyenge, hogy nem egy szoftver óriás fejleszti. Könnyű fikázni, meg mondani valamire, hogy nem csinálom, meg nem lehet, mert szarok a feltételek, az már egy kicsit nehezebb ha az ember végigküzdi magát az ilyen lehetetlennek tűnő feladatokon és összedobb valami használhatót.
Van egy alkalmazás, ami 12 éves, és van egy másik, amit én csinálok kb egy éve, és az elsőt kellene integrálni a másodikba, ami valóban nem lett túl szépen megvalósítva, de akkor és ott a célnak megfelelt, bár én nem úgy csináltam volna. Most pedig, mivel használatban van, nem lehet kidobni, amíg a másik nincs kész, erre kellene egy átmeneti megoldás, majd utána lehetne kidobni az mdb-t. De tudod a szoftverek vannak az üzletért és nem fordítva. Mondhatom, hogy dobjuk ki, aztán pár hét átállás olyan veszteséget okoz a cégnek, hogy egy főnöknek sem lesz kedve a rendszer konzisztenségét bámulva mosolyogni.
Én folyamatosan hasonló cipőben járok, nem győzzük kidobálni a régi szarokat. Mostanában ha minden igaz végre a PHP-s szutykok lesznek soron. Az access-es fosok kidobálása meg már több, mint egy éve tart.
Én csak azon mosolyogtam nagyon jót, hogy amikor az ember fejleszt, óhatatlanul is felteszi a kérdést, hogy mire akarom ezt a rendszert használni, milyen más rendszerekhez kell (majd) kapcsolódnia, milyen platformon, milyen nyelven érdemes nekiállni a fejlesztésnek, milyen régi szart tudok esetleg kiváltani vele stb...
Ha egyszer windows vonal, akkor legyen windows vonal. Ha linux, akkor legyen linux. Nincsen annál nagyobb szopás, mint amikor az ember linux-os PHP-ról próbál meg MS SQL-el kommunikálni (lehet persze, ahogy az mdb-vel is).
Én napi szinten párhuzamosan programozok PHP-ben, .Net-ben, és Vbscriptben (beleértve mindenféle makrót is). Ezek mellett linuxon van PostgreSQL-ünk, windowsokon van MS SQL-ünk, és Oracle-ünk. Szóval tudom, hogy milyen az amikor régi megörökölt szarokat kell párosítani. Manapság már meg se próbálom (ha nem muszáj), eleve úgy futok neki bárminek, hogy mit lehet egy közös modern techonlógiával kiváltani, ha már egyszer hozzá kell nyúlni. Vagy minden közé webservice-eket írok, kommunikáljanak azok egymással a megfelelő platformokon (lásd SOA).
És nem ezzel van bajom, hanem ismétlem azon mosolyogtam, hogy hogy lehet ennyire öncélúan, önszopató módon új rendszert fejlesztened, ahelyett hogy kiváltottál volna vele egy régi rendszert.
Én kérek elnézést!
Ezzel az SQL paranccsal mi a hiba?
UPDATE log SET DateTime=DateAdd(hh,1, DateTime) WHERE DateTime>{ ts '2012-07-01 06:00:00.000' }
A log táblában a DateTime mező megfelelő értékeihez akarnék 1 órát hozzáadni. Módosított dátummal az óraátállításhoz kellene. Midig elszáll, hogy az UPDATE szintaktikailag helytelen... 
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
Erre rájöttem már, hogy hülyeség, de nem tudom még így se megoldani, hogy növelje az órát. Elvileg a DateTime egy double típusú szám, szóval megcsinálhatnám ezt:
UPDATE log SET DateTime=1
De ez is szintaktikai hibás.
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
Ütném azt a barmot, aki leprogramozott egy beléptető rendszert úgy, hogy DateTime a mezőnév. log.DateTime-mal működik... 
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
ha megtalalod, szolj, segitek megverni
Mert nem rajtam állt a dolog, és amúgy adva van a Linuxos környezet még pár MS-es egység van, amelyek folyamatosan ki lesznek dobva, csak közben meg kell küzdeni azokkal, akik anno ezeket telepítették, és meg kell értetni velük, hogy az új megoldás legalább azt fogja tudni A PHP-val amúgy nem tudom mi a baj
Amennyire én értettem, rákényszerítik a Linux-környezetet, amiben használnia kell a meglévő, ósdi fosadék rendszert, ami alapvetően MS-alapú, és jelenleg egyszerűbb hozzátákolni némi plusz PHP-kódot, hogy elérje/módosítsa az adatokat, mint az egészet átültetni egy totál új rendszerbe (új adatbázist használva, új alkalmazást fejlesztve), mivel az új rendszer fejlesztése, a régi lelövése épp túl nagy időbeli és anyagi befektetést igényelne. Nyilván ő sem szívesen választotta ezt a gányolást, de ha ez van, hát akkor ez van... ne oltsd le szegényt azért, mert időszűkében kényszermegoldást választ, valószínű, hogy rövidebb alatt sikerült működő tákolmány megoldást találnia, mint amennyi idő alatt egy új rendszert kialakított volna, tulajdonképpen nem ő a hibás azért, hogy kapott egy szar feladatot, egy gány adatbázist és egy szar alkalmazást. Feltételezem és remélem, hogy majd áttérnek normális rendszerre.
[ Szerkesztve ]
Sk8erPeter
Partvonalról könnyebb bekiabálni, hogy én bezzeg...
- http://pazsitz.hu -
Most remélem ezt nem rám értetted, még ha az enyémhez is fűzted a kommentedet...
Lényegében én is ezt magyaráztam.
Sk8erPeter
abszolút
Nagyjából igaz amit feltételeztél, a különbség, hogy nincs kényszer, egy helyzet van, hogy van két nem túl kompatibilis eszköz és felmerült az egyik integrálása a másikba.
De úgy néz ki, hogy le lehet cserélni és zöld utat kapok a mysql-es megvalósításra, a dolog amúgy is csak ideiglenes lett volna, amíg el nem készül a php mysql verzió.
Ja, hát a "kényszert" magára a helyzetre értettem, hogy a régi szar rendszerhez kell igazodnod. Aztán lehet, hogy csak túl kevés információ birtokában vagyok a helyzetetekkel kapcsolatban, és túl jóindulatúan közelítem meg a kérdést. ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Sk8erPeter
Sziasztok!
Sqlplus-ban, hogyan kell csonkolni a szóközöket, amikkel kitölti a mezőket? Sajnos nem tudom fix-en megmondani, milyen hosszúak a mezőim.
Előre is köszönöm!
Üdv. Yush
Ha a saját mezőid, akkor talán nem char-t, hanem varchar-t kellene használni.
Másrészt meglepő módon Trim-el tudod a szóközöket csonkolni.
Én kérek elnézést!
nem erről van szó, ha van egy varchar(50) típusú mező, az sqlplus-ban 50 karakter széles oszlopként fog megjelenni, akkor is, ha mondjuk csak 10 betű a leghosszabb szöveg, és tele lesz felesleges szóközökkel
a trimmel az adatot lehet csonkolni, nem az outputot
erre lehet felső korlátot/formátumot beállítani, pl. 20 alfanumerikus karakter
SQL> column oszlop1 format a20
ekkor ha belefér-belefér, ha nem akkor eltöri és új sorba teszi, de ez a viselkedés is állítható
Yuschenko viszont úgy vettem ki azt szeretné, hogy mindig az aktuálisan megjelenített leghosszabb érték hosszát vegye fel az oszlop - amit meg nem lehet
[ Szerkesztve ]
Helló!
Köszi a választ. Ezek Varchar2 típusúak. Tegnap sokat játszadoztam, végülis csak úgy tudtam helyes csv formátumú exportot csinálni, hogyha a select után kiválaszott oszlopok közé ||';'||-t raktam.
Üdv. Yush
[ Szerkesztve ]
Legjobb tudomásom szerint az sqlplus-ban tényleg csak ezt lehet csinálni, hogy összefűzöd az oszlopokat a ";"-vel.
A sorvégi space-t tudod levágni a
SET TRIMS ON
sqlplus paranccsal.
=Kilroy was here============================ooO=*(_)*=Ooo=======
Köszi a választ!
Ezzel mégis milyen szintaktikai hiba van?
INSERT INTO log (DateTime, TypeID) VALUES ({ ts '1990-12-31 00:00:00' } , 1)
Access adatbázis, ODBC-n kerezstül Delphiben szeretném elérni.
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
lehet megint a DateTime kavar be neki, próbáld meg az oszlopnevek felsorolása nélkül
INSERT INTO log VALUES ({ ts '1990-12-31 00:00:00' } , 1)
Még mindig szintaktikai hiba...
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
Nem az a baj, hogy a "log" egy foglalt név? Ilyen problémával már találkoztam MySQL-nél, és ott az a megoldás, hogy köréteszed a visszafelé dőlő aposztrófot, aminek most nem jut eszembe a neve
Tehát
log
helyett
`log`
De mindez Access-ben nem rémlik, megy-e, szerencsére nem sok dolgom volt Access-szel.
[ Szerkesztve ]
Sk8erPeter
Én meg nem mondom, hogy a log foglalt-e, de másik ezer SELECT meg DELETE megy így is, hogy log.
Egyébként kipróbáltam, de ugyanaz, szintaktikai hiba az insert into utasításban.
u.i.: Remélem nem ilyen gondom van...
[ Szerkesztve ]
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
INSERT INTO log (DateTime, TypeID) VALUES ({ ts '1990-12-31 00:00:00' } , 1)
1. próbáld ki kapcsos zárójellel a log-ot [log]-ként, lehet hogy az access a log-ot valami parancsszóként értelmezné tábla név helyett
2. { ts '1990-12-31 00:00:00' } - ez mi??? Valami ilyesmit próbálnék meg helyette: #2009-04-21 14:25:53# esetleg #'2009-04-21 14:25:53'#
3. Access-be belépve kapod ezt, vagy delphi-ből futtatva? Mert ha delphi-ből, akkor én megpróbálnám a helyedben access query-ből közvetlenül.
Remélem segítettem, nagyon igyekszek távol tartani magam az access-től.
[ Szerkesztve ]
Én kérek elnézést!
és hány oszlopa van a táblának? mert ez ugye csak akkor helyes ha az összes oszlopnak adsz értéket a values részben
másik dolog ez a kapcsos zárójeles trükközés, access-hez semmit nem értek, nincs valami egyszerűbb módja a dátumbeállításnak, ami biztosan jó? (NULL-t megeszi pl. az a oszlop?)
Biztos a timestamppel van gondja. A DateTime full szívás, bármilyen adatbázisban
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
Azért ezzel vitatkoznék. Nem szívás az, legalábbis az általam használt mssql, mysql, postgresql esetekben.
Én kérek elnézést!
1. Sajna így se volt jó
2. Próbáltam az általad említett verziókat is, de nem működtek. Illetve az én formátumom a programban egyéb helyeken tökéletesen működik, ezért is használom ezt.
3. Delphiben futtatva kapom. Hamarabb találtam megoldást, mintsem ki kellett volna próbálni Access Query-ben
@-Zeratul-
Próbáltam a NULL értéket, de nem fogadta el.
Végül a megoldás. Ha felsoroltam az oszlopneveket (egyik DateTime) szintaktikai hiba. Kínomban beírtam, hogy log.DateTime, de ez értelem szerűen szar, de máshol így működött. Végül azt rontottam el, hogy ha elhagyom az oszlopneveket, akkor minden mezőt ki kell tölteni, pont ahogy írtad. Szóval a megoldás valami ilyesmi lett a többi oszlop adataival értelem szerűen:
INSERT INTO log VALUES ( {ts '1995-12-31 01:15:15'}, *, *, '**', '**', *, *, **, *, *)
@sztanozs
Én is úgy érzem, hogy csak a szívás van vele. Most megint olyat kapok máshol, hogy a '2012-07-24 10:26:25' nem megfelelő DateTime formátum... Csak akkor tudnám mi az...
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
Gondolom Delphi-ben is van prepared statement. Tessék azt használni és nem stringet konkatenálni...
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
Hát, nem igazán tudom miről beszélsz.
Végül nem a Stingből csináltam DateTime-ot, hogy összehasonlítsam másik DateTime-mal, hanem a DateTime-ből Stringet, és a két Stringet hasonlítottam össze.
"Mindent azért kell tudni mert kérdezik, nem azért mert hasznos."
"A DateTime full szívás, bármilyen adatbázisban "
Miért?
Sk8erPeter
Ha sql parancsot konkatenálsz - amit ugye nem illendő - akkor ahány adatbáziskezelő annyi féle datetime megvalósítás, sőt a datetime string formátum még kultúra érzékeny is.
egy 10/11/12-ről megmondani, hogy mi volt az eredeti dátum 33%-os eséllyel lehet - és az adatbáziskezelő is ilyen eséllyel vesz fel jó értéket.
Persze, ha prepared statement-et használ az ember, akkor rögtön nincs ilyen gond... (láttam is róla egy jó képet itt valahol ) De ugye a fenti esetben sem erre láttunk példát.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
Ja, hogy így. Igen, mondjuk adatbázisonként eltérhet a formátum, MySQL-ben ilyen: [link]
"MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'."
MSSQL-ben: [link]
"Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds"
Egyébként konkrétan azért kérdeztem vissza, mert feltételezem, a TÁROLÁS módja a háttérben (tehát magának az adatbázis-kezelőnek a szintjén) viszont általánosan van megoldva, tehát ez alapján magából a tárolt értékből ki lehet nyerni a megfelelő dátumot, legfeljebb lekérdezéskor előfordulhat, hogy valaki nem megfelelő formátumban adja meg a datetime-ot, és akkor nem azt az eredményt kapja, amit elvárt; vagy épp feltöltéskor más formátumban adja meg, mint ami az elvárt, és "rossz" datetime tárolódik, nem?
Mondjuk egy UNIX timestamp legalább valszeg mindenhol ugyanolyan.
"Ha sql parancsot konkatenálsz - amit ugye nem illendő - akkor ahány adatbáziskezelő annyi féle datetime megvalósítás"
Itt viszont nem értem, miért emeled ki a konkatenálást, mert elvileg akkor épp azért, amiről beszélünk, tök mindegy, hogy most konkatenálva adtál át rossz formátumot, vagy prepared statementként.
Gondolom erre a képre gondoltál: [link].
Sk8erPeter
Prepared Statementnél a programnyelv natív formájában tudod átadni a változót, nem kell előtte stringgé alakítani. Ezt konkatenált utasítás esetén nem tudod megtenni.
Igen ezt volt
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
"Gondolom erre a képre gondoltál: [link]. "
Haha, ez király! 
[ Szerkesztve ]
=Kilroy was here============================ooO=*(_)*=Ooo=======
Attól függ, milyen prepared statementről beszélsz, mert most már nem egyértelmű számomra.
=========================
(#1294) rum-cajsz : jaja, ArchElf készítette, mert a t×künk tele volt a PHP topicban a sok konkatenált fosadék query-vel. 
Elég találó.
[ Szerkesztve ]
Sk8erPeter
Ahol paraméterként adod át a command változóit.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
Most akkor mutatok két lehetséges változatot, csak kiragadott példa:
MySQL Prepared Statements
PHP + PDO Prepared Statements
Sk8erPeter
és ez még csak a PHP. Van még néhány nyelv, ahol nem is prepared statement-nek hívják
A lényeg azonban ugyanaz, kerülendő a konkatenálás.
Én kérek elnézést!
Rosszul állt az elnevezés a fejemben - sorry 
Szóval paraméterezett SQL utasítást kell használni
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
Még mindig nem értem, hogy ez önmagában miért oldaná meg azt, ha a fejlesztő vagy a user rossz inputot akarna megadni a datetime mezőhöz. A kiindulópont ez volt, erre állítottad, hogy ez egy megoldás lehet, de még mindig nem mondtad el, hogyan kínál ez áthidaló megoldást nyelvektől függetlenül.
===
(#1298) martonx : igen, de most nem ez a lényeg, hanem hogy ez hogyan oldja meg a rossz formátumok problémáját (ha már ez volt az állítás), amiről korábban szó volt.
Sk8erPeter
