Új hozzászólás Aktív témák

• Sk8erPeter nagyúr

  #1300

  #1299 sztanozs

  2012-07-25 11:56:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1299 sztanozs

  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.

• sztanozs veterán

  #1299

  #1297 Sk8erPeter

  2012-07-25 10:34:44

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #1297 Sk8erPeter

  Rosszul állt az elnevezés a fejemben - sorry
  Szóval paraméterezett SQL utasítást kell használni

• martonx veterán

  #1298

  #1297 Sk8erPeter

  2012-07-25 08:50:36

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1297 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.

• Sk8erPeter nagyúr

  #1297

  #1296 sztanozs

  2012-07-24 22:24:57

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1296 sztanozs

  
  Most akkor mutatok két lehetséges változatot, csak kiragadott példa:

  MySQL Prepared Statements
  PHP + PDO Prepared Statements

• sztanozs veterán

  #1296

  #1295 Sk8erPeter

  2012-07-24 22:08:50

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #1295 Sk8erPeter

  Ahol paraméterként adod át a command változóit.

• Sk8erPeter nagyúr

  #1295

  #1293 sztanozs

  2012-07-24 20:15:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1293 sztanozs

  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ó.

• rum-cajsz őstag

  #1294

  #1292 Sk8erPeter

  2012-07-24 16:05:40

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  #1292 Sk8erPeter

  "Gondolom erre a képre gondoltál: [link]. "

  Haha, ez király!

• sztanozs veterán

  #1293

  #1292 Sk8erPeter

  2012-07-24 14:40:49

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #1292 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

• Sk8erPeter nagyúr

  #1292

  #1291 sztanozs

  2012-07-24 14:32:34

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1291 sztanozs

  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].

• sztanozs veterán

  #1291

  #1290 Sk8erPeter

  2012-07-24 13:57:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #1290 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.

• Sk8erPeter nagyúr

  #1290

  #1285 sztanozs

  2012-07-24 12:52:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1285 sztanozs

  "A DateTime full szívás, bármilyen adatbázisban "
  Miért?

• sanzi89 addikt

  #1289

  #1288 sztanozs

  2012-07-24 11:30:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  #1288 sztanozs

  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.

• sztanozs veterán

  #1288

  #1287 sanzi89

  2012-07-24 11:17:05

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #1287 sanzi89

  Gondolom Delphi-ben is van prepared statement. Tessék azt használni és nem stringet konkatenálni...

• sanzi89 addikt

  #1287

  #1283 martonx

  2012-07-24 10:26:50

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  #1283 martonx

  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...

• martonx veterán

  #1286

  #1285 sztanozs

  2012-07-23 20:03:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1285 sztanozs

  Azért ezzel vitatkoznék. Nem szívás az, legalábbis az általam használt mssql, mysql, postgresql esetekben.

• sztanozs veterán

  #1285

  #1283 martonx

  2012-07-23 16:43:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #1283 martonx

  Biztos a timestamppel van gondja. A DateTime full szívás, bármilyen adatbázisban

• bpx őstag

  #1284

  #1280 sanzi89

  2012-07-23 15:44:38

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1280 sanzi89

  é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?)

• martonx veterán

  #1283

  #1278 sanzi89

  2012-07-23 15:41:52

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1278 sanzi89

  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.

• sanzi89 addikt

  #1282

  #1281 Sk8erPeter

  2012-07-23 15:37:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  #1281 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...

• Sk8erPeter nagyúr

  #1281

  #1280 sanzi89

  2012-07-23 15:23:16

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1280 sanzi89

  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.

• sanzi89 addikt

  #1280

  #1279 bpx

  2012-07-23 15:13:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  #1279 bpx

  INSERT INTO log VALUES ({ ts '1990-12-31 00:00:00' } , 1)

  Még mindig szintaktikai hiba...

• bpx őstag

  #1279

  #1278 sanzi89

  2012-07-23 15:10:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1278 sanzi89

  lehet megint a DateTime kavar be neki, próbáld meg az oszlopnevek felsorolása nélkül

• sanzi89 addikt

  #1278 2012-07-23 15:04:50

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  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.

• Yushchenko őstag

  #1277

  #1275 rum-cajsz

  2012-07-23 13:11:39

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Yushchenko

  őstag

  #1275 rum-cajsz

  Köszi a választ!

• rum-cajsz őstag

  #1275

  #1274 Yushchenko

  2012-07-20 15:09:00

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  #1274 Yushchenko

  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.

• Yushchenko őstag

  #1274

  #1272 martonx

  2012-07-20 14:59:51

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Yushchenko

  őstag

  #1272 martonx

  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

• bpx őstag

  #1273

  #1272 martonx

  2012-07-20 14:49:43

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1272 martonx

  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

• martonx veterán

  #1272

  #1271 Yushchenko

  2012-07-20 14:41:56

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1271 Yushchenko

  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.

• Yushchenko őstag

  #1271 2012-07-19 17:12:40

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Yushchenko

  őstag

  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

• Sk8erPeter nagyúr

  #1270

  #1269 wolandino

  2012-07-19 13:11:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1269 wolandino

  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.

• wolandino tag

  #1269

  #1266 Sk8erPeter

  2012-07-18 19:05:14

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1266 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ó.

• Sk8erPeter nagyúr

  #1268

  #1267 PazsitZ

  2012-07-18 15:14:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1267 PazsitZ

  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.

• PazsitZ addikt

  #1267

  #1266 Sk8erPeter

  2012-07-18 14:21:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  PazsitZ

  addikt

  #1266 Sk8erPeter

  Partvonalról könnyebb bekiabálni, hogy én bezzeg...

• Sk8erPeter nagyúr

  #1266

  #1260 martonx

  2012-07-18 14:14:54

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1260 martonx

  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.

• wolandino tag

  #1265

  #1260 martonx

  2012-07-18 14:04:48

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1260 martonx

  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

• tisn veterán

  #1264

  #1263 sanzi89

  2012-07-18 13:17:56

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  tisn

  veterán

  #1263 sanzi89

  ha megtalalod, szolj, segitek megverni

• sanzi89 addikt

  #1263

  #1262 sanzi89

  2012-07-18 12:43:54

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  #1262 sanzi89

  Ütném azt a barmot, aki leprogramozott egy beléptető rendszert úgy, hogy DateTime a mezőnév. log.DateTime-mal működik...

• sanzi89 addikt

  #1262

  #1261 sanzi89

  2012-07-18 11:48:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  #1261 sanzi89

  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.

• sanzi89 addikt

  #1261 2012-07-18 11:35:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sanzi89

  addikt

  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...

• martonx veterán

  #1260

  #1259 wolandino

  2012-07-17 22:46:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1259 wolandino

  É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.

• wolandino tag

  #1259

  #1258 martonx

  2012-07-17 18:30:58

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1258 martonx

  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.

• martonx veterán

  #1258

  #1257 wolandino

  2012-07-17 11:11:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1257 wolandino

  "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.

• wolandino tag

  #1257

  #1256 Sk8erPeter

  2012-07-17 10:27:03

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1256 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.

• Sk8erPeter nagyúr

  #1256

  #1255 wolandino

  2012-07-16 14:44:47

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1255 wolandino

  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.

• wolandino tag

  #1255

  #1253 tisn

  2012-07-16 10:59:47

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1253 tisn

  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.

• bpx őstag

  #1254

  #1253 tisn

  2012-07-16 10:17:16

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1253 tisn

  kedvencem a német "kollégák" 'ä' és 'ß' karakterekkel kezdődő táblái...

• tisn veterán

  #1253

  #1252 wolandino

  2012-07-16 09:59:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  tisn

  veterán

  #1252 wolandino

  Ekezetes tablanev? hova jutott ez a vilag...

• wolandino tag

  #1252

  #1251 martonx

  2012-07-16 09:52:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1251 martonx

  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

• martonx veterán

  #1251

  #1249 wolandino

  2012-07-16 00:10:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1249 wolandino

  ú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

• wolandino tag

  #1250

  #1248 Lortech

  2012-07-14 21:58:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1248 Lortech

  köszi, meg fogom nézni ezt is

• wolandino tag

  #1249

  #1247 martonx

  2012-07-14 21:58:06

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1247 martonx

  Nem fog működni?
  Akkor nézd meg ezt, mert ezzel végre működik a dolog:

  http://www.lorenzoingrilli.it/database-access-mdb-da-linux-via-odbc
  
  Már csak a karakterkódolással kapcsolatos gondokat kell megoldanom

• Lortech addikt

  #1248

  #1244 wolandino

  2012-07-14 21:47:52

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Lortech

  addikt

  #1244 wolandino

  Ha elég csak kinyerni az adatokat belőle, és nem riadsz vissza egy kis barkácsolástól, akkor megpróbálhatod ezt: [link]

  Egyébként csak fizetős driverekről tudok.

• martonx veterán

  #1247

  #1246 wolandino

  2012-07-14 19:47:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1246 wolandino

  Nem ismerem a lehetőségeidet, csak jeleztem, hogy amit szeretnél nem fog menni. Mindegy, hogy neten mit találtál, amíg az MS nem írja meg az Access ODBC-t linux alá, addig nem fog működni amit szeretnél. Márpedig az MS soha nem fogja az Access-t linux alá megírni.
  És az MS Access akkor sem egyenlő MS SQL-el, ez olyan mintha egy Skoda Fabia-ra meg egy Porsche-ra mondanád, hogy de mindkettőt a VW cég gyártja.

• wolandino tag

  #1246

  #1245 martonx

  2012-07-14 14:35:38

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  #1245 martonx

  Igen, ez egy access adatbázis, de MS ez is.
  A neten írnak rá megoldást, de az nem műkszik nekem.
  Ha rajtam múlna nem is használnám, de van egy eszközöm, ami ilyet állít elő, és van egy szerverem, ami meg ubuntus környezetben fut,
  Ezek konstansok. Max annyit tudok tenni, hogy megpróbálom a wiondowsos gépen elérni az Adatbázist linux alól, de az meg már mind1.

• martonx veterán

  #1245

  #1244 wolandino

  2012-07-14 14:26:27

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1244 wolandino

  Te kevered a szerzont a fazonnal. MS SQL-ről beszélsz, mikor a connection stringet MS Access-re mutat.
  Ráadásul mindezt Linuxon???
  Nem fog menni. Megoldási lehetőségek:
  1. Miért ragaszkodsz a Linux-hoz, ha már MS alapú az adatbázisod? Futtasd windows-on a PHP-t.
  2. Elfelejted az mdb-det, és használsz helyette valami más SQL-t, mondjuk sqlite, mysql, postgresql. Ezek mind futnak linux-on is.

• wolandino tag

  #1244 2012-07-14 13:58:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  wolandino

  tag

  Sziasztok!

  Van egy MS SQL adatbázisom, amit linux környezetben szeretnék használni és ugyancsak arról a linux szerverről elérni, amin nem mellesleg PHP fut.
  Windows-os környezetben ugyanezt pofonegyszerűen elértem egy ilyen kóddal:

  $connection = odbc_connect("Driver={Microsoft Access Driver (*.mdb)};DBQ=". realpath("./teszt.mdb").";", "ADODB.Connection", "");

  de linux alatt sehogy sem akar összejönni, pedig már végignyálaztam a netet vagy kétszer ezügyben

  Ha tudna valaki segíteni, akkor nagyon hálás lennék.

  Köszönettel,
  W.

• SektorFlop aktív tag

  #1243

  #1239 Sk8erPeter

  2012-07-13 16:49:15

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  SektorFlop

  aktív tag

  #1239 Sk8erPeter

  tényleg célszerűbb lenne, meg se fordul a fejemben ez a megoldás.

• Fecogame veterán

  #1242

  #1241 rum-cajsz

  2012-07-13 13:10:21

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Fecogame

  veterán

  #1241 rum-cajsz

  SMF a fórummotor

  Update: Átneveztem benne a prefixet, erre kiírja, hogy a settings tábla nem létezik. Backupot visszaállítottam, úgy is ugyanaz az eredmény...

• rum-cajsz őstag

  #1241

  #1238 Fecogame

  2012-07-13 12:40:51

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  #1238 Fecogame

  Hát, ennek a megoldása függ attól, hogy milyen fórummotort használsz. Mert nem elég átnevezned a táblákat, hanem az összes config táblában és config fájlban is át kell állítanod az új prefixet.

  Én azt próbálnám meg, hogy csinálok egy vadonatúj telepítést az új prefixekkel, és utána betölteném az új táblákba a régiek tartalmát. Ez után leellenőrizném az összes táblát, hogy van-e benne olyan config sor, amiben szerepel táblanév, mert ha igen, akkor azt is javítanám.
  Csak ez után indítanám el a fórumot, és kipróbálnám, hogy jól működik-e. Ha igen, akkor mehet élesben, ha nem, akkor keresni kell valami más megoldást.

  A másik lehetőség, hogy a fórum motor támogatja a táblák átnevezését, akkor könnyebb dolgod van.

• Fecogame veterán

  #1240

  #1239 Sk8erPeter

  2012-07-13 12:33:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Fecogame

  veterán

  #1239 Sk8erPeter

  Adott két fórum egy tárhelyen, és ezekhez 2 külön adatbázis tartozik ( jelenleg ).

  Ezt a kettő adatbázist kell egybe összeraknom, mert az új tárhelyen csak egy használatára van lehetőség.

• Sk8erPeter nagyúr

  #1239

  #1220 SektorFlop

  2012-07-13 11:37:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1220 SektorFlop

  Más, mert a többiek az eredeti kérdést már megoldották: miért nem használsz prepared statementeket? Ez a query-konkatenálás nagyon csúnya és kerülendő megoldás.

  (#1238) Fecogame :
  Mit értesz azalatt, hogy "egybeolvasztani"? Magyarul egy adatbázisba rakni? Mi vele a problémád?
  Amúgy azonos tárhely alatt akarsz két fórummotort használni, vagy két különbözőn?
  Ha az első, akkor annak mi értelme? Ha a második változat, akkor viszont meg kell oldani a külső hozzáférést is az adatbázishoz.

• Fecogame veterán

  #1238

  #1237 rum-cajsz

  2012-07-13 09:44:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Fecogame

  veterán

  #1237 rum-cajsz

  Oké Akkor már csak az a kérdés, hogy a két ( már meglévő ) adatbázist hogyan tudom egybeolvasztani?

• rum-cajsz őstag

  #1237

  #1234 Fecogame

  2012-07-13 09:35:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  #1234 Fecogame

  Ha más az előtag, akkor tökéletes az elgondolásod.

• Fecogame veterán

  #1236

  #1235 martonx

  2012-07-13 09:27:18

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Fecogame

  veterán

  #1235 martonx

  Szolgálatóilag korlátozva van. És az egyik fórum a fődomainen van, a másik pedig aldomain

• martonx veterán

  #1235

  #1234 Fecogame

  2012-07-13 09:21:55

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1234 Fecogame

  úgy működhet.
  Másrészt nem értem, hogy ha valahol kt különböző domaint tudsz hostingolni, akkor miért ne tudnál domainenként létrehozni egy-egy db-t? Sőt biztosan lehetséges, maximum nem is gondoltál rá.

• Fecogame veterán

  #1234

  #1233 rum-cajsz

  2012-07-13 08:59:52

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Fecogame

  veterán

  #1233 rum-cajsz

  A fórummotor ugyanaz, de a beállítások már nem. És ha más-más előtaggal működik a két fórum, akkor sem működhet ez a felállás?

• rum-cajsz őstag

  #1233

  #1232 Fecogame

  2012-07-13 01:47:01

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  #1232 Fecogame

  elméletileg máködhet, ha a fórumokat ugyanarra az adatbázisra állítod be, de gyakorlatilag ennek a kivitelezése szerintem nagyon sok hibát/problémát fel fog vetni.
  Főleg ha a két fórum beállításai nem 100%-osan ugyanazok lesznek. Mondjuk más témákat telepítesz egyikre, mint a másikra, stb....

• Fecogame veterán

  #1232 2012-07-12 20:53:42

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Fecogame

  veterán

  Ha adott két fórummotor és egyetlen adatbázist vagyok kénytelen használni, de két userrel, az működhet? Ha igen, akkor hogyan tudom a jelenlegi kettőt egybeolvasztani?

  

• martonx veterán

  #1231

  #1228 lakisoft

  2012-07-06 13:45:39

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1228 lakisoft

  A példák mindig egyszerűek. A megvalósítás, meg a gyakorlat már bonyolultabb tud lenni.
  De ez az életben is ilyen egyszerű, mint a példámban.

• lakisoft veterán

  #1230

  #1229 rum-cajsz

  2012-07-06 08:31:57

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  #1229 rum-cajsz

  Összepakol egy stringet és le akarja futtatni. Ennyi sikerült belőle megérteni .

• rum-cajsz őstag

  #1229 2012-07-06 08:29:28

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  Hihetetlenek vagytok, hogy ebből a lent megadott selectből ki tudtátok találni, hogy mit akar kérdezni az illető....
  Nekem nem ment, pedig elolvastam kétszer is, hátha figyelmetlen voltam.

• lakisoft veterán

  #1228

  #1227 martonx

  2012-07-06 08:29:15

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  #1227 martonx

  nem de azért az életben nem ilyen egyszerű példák vannak .

• martonx veterán

  #1227

  #1226 lakisoft

  2012-07-06 08:19:03

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1226 lakisoft

  update table1
  set valami = t2.valami
  from table1 t1
  join table2 t2 on t1.id = t2.id

  volt benne új?

• lakisoft veterán

  #1226

  #1225 martonx

  2012-07-06 07:32:14

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  #1225 martonx

  Mond meg kapásból hátha van benne új számomra

• martonx veterán

  #1225

  #1224 SektorFlop

  2012-07-06 07:29:37

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  martonx

  veterán

  #1224 SektorFlop

  join-os update-nek annyira más minden SQL nyelvjárásban a szintaktikája, hogy ajánlom a guglit. MSSQL-ben kapásból megmondtam volna.
  Mondjuk ilyen triviális kérdésnél egyébként is elsőre guglizni illene...

• SektorFlop aktív tag

  #1224

  #1223 lakisoft

  2012-07-06 06:01:17

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  SektorFlop

  aktív tag

  #1223 lakisoft

  SQLite, Android Java-ba kell.

• lakisoft veterán

  #1223

  #1222 SektorFlop

  2012-07-06 01:10:19

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  #1222 SektorFlop

  Igazán nincs mit. Milyen adatbázis kezelőben akarod ezt megcsinálni?

• SektorFlop aktív tag

  #1222

  #1221 lakisoft

  2012-07-05 23:38:03

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  SektorFlop

  aktív tag

  #1221 lakisoft

  köszi a gyors választ, én is utána olvasok.

• lakisoft veterán

  #1221

  #1220 SektorFlop

  2012-07-05 21:52:49

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  #1220 SektorFlop

  Neked olyan kell, hogy "join in update" az nem teljesen így kell megoldani, bár a logikája hasonló. Pont ma csináltam ilyet. Utánanézek.

• SektorFlop aktív tag

  #1220 2012-07-05 19:57:44

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  SektorFlop

  aktív tag

  Lenne egy olyan problémám, hogy van 2 táblám.

  Fizetes:
  _id
  FizOsszeg
  FizEgyenleg
  FizHonap
  FizEv

  Terheles:
  _id
  TerOsszeg
  TerNev
  TerAllapot
  TerDatum
  FizID -> ez lenne az összekötő!

  Szereznék egy Update-et végezni és ha lehet csak sql-en belül szeretném megoldani. Elképzelésem szerint volt egy ilyen próbálkozásom, de sikertelenül...

  db.execSQL("UPDATE "+TerhelesTable+" SET "+TerhelesHonap+" = IN (SELECT "+FizetesID+" FROM "+FizetesTable+" ORDER BY " +FizetesID+ " DESC LIMIT 1)");

• lakisoft veterán

  #1219

  #1218 lakisoft

  2012-07-02 13:50:56

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  #1218 lakisoft

  Elvileg itt a network DTS-sel meg lehet oldani a dologot:

  Use this procedure to enable network DTC access.

  You can use this procedure to enable network DTC access on Windows Vista® or Windows Server® 2008. This procedure should be followed to allow remote computers to be enlisted in Microsoft Distributed Transaction Coordinator (MSDTC) transactions over the network.

  Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

  To enable network DTC access and configure Windows Firewall on Windows Vista or Windows Server 2008
  Click Start, click Run, type dcomcnfg and then click OK to open Component Services.

  In the console tree, click to expand Component Services, click to expand Computers, click to expand My Computer, click to expand Distributed Transaction Coordinator and then click Local DTC.

  Right click Local DTC and click Properties to display the Local DTC Properties dialog box.

  Click the Security tab.

  Set the following options on the Security tab of the Local DTC Properties dialog box and click OK.

  Ezt követően ezt a hibaüzit kapom:
  Msg 233, Level 20, State 0, Line 0
  Átviteli szintű hiba történt a kérés kiszolgálóra történő küldésekor. (provider: Megosztott memória szolgáltatója, error: 0 - Nincs folyamat a pipe másik végén.)
  Megoldása elvileg egy hotfix:
  [link]

  Remélem kijavítja mert igen kemény szívás lesz ha nem tudod hálózati meghajtóról importálni.

• lakisoft veterán

  #1218 2012-07-02 13:36:05

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  MSSQL 2008-al kaptatok már ilyen hibaüzenetet:
  OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "(null)" returned message "A következő elérési út érvénytelen: 'U:\xxx.mdb'. Ellenőrizze, hogy helyesen adta-e meg az elérési utat, és hogy kapcsolódott-e a fájlt tartalmazó kiszolgálóra.".
  Msg 7303, Level 16, State 1, Line 1
  Cannot initialize the data source object of OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "(null)".

  Az U hálózati meghajtó ugye. És nem tudja megnyitni az adatbázis fájlt.
  Mi ilyenkor a teendő?

• Sk8erPeter nagyúr

  #1217

  #1215 bpx

  2012-07-02 00:31:55

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1215 bpx

  Na, a kérdés maga annyira megzavart, hogy már én is félrebeszéltem, meg pontatlanul is írtam, bocsi. A kérdező azt írta, hogy "A dátum 2003.11.26. 10:28:14 ilyen formátumban van.", én ebből úgy értelmeztem, hogy valamilyen oknál fogva string típusként van TÁROLVA az adatbázisban (most szándékosan írtam tárolást!! Mindegy, hogy varchar vagy egyéb ilyen jellegű típusról van szó, és NEM a dátumformátumok valamelyikéről, aminek nyilván megvan a maga tárolási módja, de attól még valamelyik tényleges dátumformátumról van szó), ezért kénytelen vagdosni, stb., de akkor valószínű félreértettem az eredeti felvetést.
  Utána már azt is félreértettem, amit Te írtál, pedig így másodszor elolvasva elég világos, hogy itt csak dátum-megjelenítési formátumot változtatsz, attól még nem tárolod másik formában.
  Akkor most megpróbálom értelmesen megfogalmazni: arra gondoltam, hogy még a megjelenítési formátumot sem biztos, hogy szerencsés, ha az ember változtatja, mert ha mondjuk egy alkalmazást megír (hogy most az asztali vagy webes, tök mindegy), ami az adatbázistól bizonyos formátumban (megjelenítési formátumban) vár adatokat, és tök más formában kapja meg, mint egy másik szerveren, akkor abból adott esetben probléma lehet - mondjuk a probléma kimerül annyiban, hogy át kell állítani a formátumot úgy, ahogy mutattad, de nem biztos, hogy azonnal leesik, mi is a gond.

• varsam őstag

  #1216

  #1209 bpx

  2012-06-28 17:00:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  varsam

  őstag

  #1209 bpx

  Köszi mindenkinek!

  A probléma annyi volt, hogy én pontokkal elválasztva akartam szűrni dátumra, amire kiírta h nem megfelelő a formátum, de átírva - jelre már oké is volt, illetve elé biggyesztettem egy to_date -et

• bpx őstag

  #1215

  #1213 Sk8erPeter

  2012-06-28 13:05:10

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1213 Sk8erPeter

  mint azt tegnap is írtam az ábrázolás és a tárolás formátuma teljesen független, te csak az megjelenítés formátumát tudod manipulálni, a dátum típusnak megvan a saját belső struktúrája

  simán lehet csak bizonyos részeket megjeleníteni, vagy akár tök hülyeséget is (ami persze még érelmezhető) beállítani format stringnek (és ugye most Oracle-ről beszélünk)

  SQL> select sysdate from dual;
  
  SYSDATE
  ---------
  28-JUN-12
  
  SQL> alter session set nls_date_format='_#!+YYYYMMDDHH24MISS';
  
  Session altered.
  
  SQL> select sysdate from dual;
  
  SYSDATE
  ------------------
  _#!+20120628130131
  
  SQL> alter session set nls_date_format='SS...:_"/=%!"YYYY!"%/%"HH24"%!"MI_DD_:MM';
  
  Session altered.
  
  SQL> select sysdate from dual;
  
  SYSDATE
  --------------------------------
  07...:_/=%!2012!%/%13%!02_28_:06
  
  SQL> alter session set nls_date_format='YYYY.MM.DD. HH24:MI:SS';
  
  Session altered.
  
  SQL> select sysdate from dual;
  
  SYSDATE
  --------------------
  2012.06.28. 13:02:59

• rum-cajsz őstag

  #1214

  #1213 Sk8erPeter

  2012-06-28 12:36:00

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  #1213 Sk8erPeter

  A dátumformátumot beállíthatod a kliens paraméterei között (mármint az oprendszerben), nem kell állandóan kiadni a lenti parancsot.

• Sk8erPeter nagyúr

  #1213

  #1211 bpx

  2012-06-28 12:18:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1211 bpx

  Ja oké, kösz, ezt nem ismertem.
  Szerk.: habár jobb akkor is a "default" formátumban tárolni, nem? Úgy könnyebben migrálható. Különben mindig oda kell írni ezt az ALTER-t, amit írtál.

• rum-cajsz őstag

  #1212

  #1202 lazlora

  2012-06-28 12:17:04

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  rum-cajsz

  őstag

  #1202 lazlora

  Itt gyakorolhatsz többféle adatbázisban is alapdolgokat: http://sqlzoo.net/

• bpx őstag

  #1211

  #1210 Sk8erPeter

  2012-06-28 12:04:06

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1210 Sk8erPeter

  ez hogy ott pont van, semmit nem jelent

  SQL> alter session set nls_date_format='YYYY.MM.DD. HH24:MI:SS';
  
  Session altered.
  
  SQL> select sysdate from dual;
  
  SYSDATE
  --------------------
  2012.06.28. 12:03:06

• Sk8erPeter nagyúr

  #1210

  #1209 bpx

  2012-06-28 11:07:19

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1209 bpx

  Azt írja, a dátum így szerepel: "2003.11.26. 10:28:14"
  Szerintem az aláhúzott rész a para, tehát hogy a 26-át jelző nap után van egy pont, szóval úgy tűnik, karaktersorozatként van tárolva (tényleg elég gázos).

• bpx őstag

  #1209

  #1207 varsam

  2012-06-27 22:57:50

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1207 varsam

  semmi jelentősége nincs, hogy a dátum milyen formátumban van ábrázolva, a dátum a tárolása a háttérben máshogy történik, szűrni úgy lehet, hogy egy másik dátumhoz hasonlítod:

  SELECT * FROM tabla WHERE datum = TO_DATE('YYYY-MM-DD HH24:MI:SS', '2012-06-27 22:52:12');

  ha a dátum karaktersorozatként van tárolva, az már régen rossz, és akkor kell string műveletekkel foglalkozni

  illetve ebben semmi PL/SQL nincs, szóval érdekelne, milyen az a PL/SQL-es szűrés/és hogy mire gondoltál

• Jester01 veterán

  #1208

  #1207 varsam

  2012-06-27 17:22:09

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Jester01

  veterán

  #1207 varsam

  Például trunc segítségével lecsapod az időt.
  Alkalmasint stringként is szétvághatod.
  Vagy akár csinálhatod like operátorral is.

• varsam őstag

  #1207 2012-06-27 17:17:17

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  varsam

  őstag

  üdv

  egyszerű kérdésem lenne. PLSQL-lel szeretnék dátumra szűrni.
  A dátum 2003.11.26. 10:28:14 ilyen formátumban van. Hogy kellene egy bizonyos dátumra szűrnöm?

  köszi

• lakisoft veterán

  #1206

  #1205 lazlora

  2012-06-19 07:57:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lakisoft

  veterán

  #1205 lazlora

  Működik, igen.

• lazlora tag

  #1205

  #1204 bpx

  2012-06-18 22:39:16

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lazlora

  tag

  #1204 bpx

  Köszönöm válaszod! Remélem működik localhostban is.

• bpx őstag

  #1204

  #1202 lazlora

  2012-06-18 22:06:48

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bpx

  őstag

  #1202 lazlora

  felraksz saját gépre valami kisebb sql szervert (mysql, postges), és máris gyakorolhatsz

• Sk8erPeter nagyúr

  #1203

  #1202 lazlora

  2012-06-18 21:57:43

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sk8erPeter

  nagyúr

  #1202 lazlora

  "ahol selectet lehet gyakorolni?"
  Hogy mi van?

  Rakj fel magadnak egyet például a kis gépecskédre...

• lazlora tag

  #1202 2012-06-18 20:50:07

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  lazlora

  tag

  Sziasztok,

  Nem tud valaki egy gyakorló szervert ahol selectet lehet gyakorolni?

  Üdv

• Jester01 veterán

  #1201

  #1199 WolfLenny

  2012-06-14 14:31:59

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Jester01

  veterán

  #1199 WolfLenny

  Az se mindegy, hogy soronként PHP-ből vagy a mysql erre kitalált LOAD DATA INFILE parancsával csinálod.

Új hozzászólás Aktív témák