Új hozzászólás Aktív témák
-
#1300
Sk8erPeter
nagyúr
sztanozs
#1299
Sk8erPeter
nagyúr
válasz
sztanozs
#1299
üzenetére
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.
-
#1299
sztanozs
veterán
Sk8erPeter
#1297
sztanozs
veterán
válasz
Sk8erPeter
#1297
üzenetére
Rosszul állt az elnevezés a fejemben - sorry
Szóval paraméterezett SQL utasítást kell használni -
#1298
martonx
veterán
Sk8erPeter
#1297
martonx
veterán
válasz
Sk8erPeter
#1297
üzenetére
é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. -
#1296
sztanozs
veterán
Sk8erPeter
#1295
sztanozs
veterán
válasz
Sk8erPeter
#1295
üzenetére
Ahol paraméterként adod át a command változóit.
-
#1295
Sk8erPeter
nagyúr
sztanozs
#1293
-
#1294
rum-cajsz
őstag
Sk8erPeter
#1292
rum-cajsz
őstag
válasz
Sk8erPeter
#1292
üzenetére
"Gondolom erre a képre gondoltál: [link]. "
Haha, ez király!
-
#1293
sztanozs
veterán
Sk8erPeter
#1292
sztanozs
veterán
válasz
Sk8erPeter
#1292
üzenetére
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
-
#1292
Sk8erPeter
nagyúr
sztanozs
#1291
Sk8erPeter
nagyúr
válasz
sztanozs
#1291
üzenetére
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].
-
#1291
sztanozs
veterán
Sk8erPeter
#1290
sztanozs
veterán
válasz
Sk8erPeter
#1290
üzenetére
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. -
sanzi89
addikt
válasz
martonx
#1283
üzenetére
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...
-
bpx
őstag
válasz
sanzi89
#1280
üzenetére
é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
válasz
sanzi89
#1278
üzenetére
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.
-
#1282
sanzi89
addikt
Sk8erPeter
#1281
sanzi89
addikt
válasz
Sk8erPeter
#1281
üzenetére
É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...
-
#1281
Sk8erPeter
nagyúr
sanzi89
#1280
Sk8erPeter
nagyúr
válasz
sanzi89
#1280
üzenetére
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.
-
#1275
rum-cajsz
őstag
Yushchenko
#1274
rum-cajsz
őstag
válasz
Yushchenko
#1274
üzenetére
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 aSET TRIMS ON
sqlplus paranccsal.
-
bpx
őstag
válasz
martonx
#1272
üzenetére
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 outputoterre 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
-
#1272
martonx
veterán
Yushchenko
#1271
martonx
veterán
válasz
Yushchenko
#1271
üzenetére
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. -
#1271
Yushchenko
őstag
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
-
#1270
Sk8erPeter
nagyúr
wolandino
#1269
-
wolandino
tag
válasz
Sk8erPeter
#1266
üzenetére
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ó. -
#1267
PazsitZ
addikt
Sk8erPeter
#1266
PazsitZ
addikt
válasz
Sk8erPeter
#1266
üzenetére
Partvonalról könnyebb bekiabálni, hogy én bezzeg...
-
#1266
Sk8erPeter
nagyúr
martonx
#1260
Sk8erPeter
nagyúr
válasz
martonx
#1260
üzenetére
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
válasz
martonx
#1260
üzenetére
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 -
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
válasz
wolandino
#1259
üzenetére
É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
válasz
martonx
#1258
üzenetére
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
válasz
wolandino
#1257
üzenetére
"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
válasz
Sk8erPeter
#1256
üzenetére
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.
-
#1256
Sk8erPeter
nagyúr
wolandino
#1255
Sk8erPeter
nagyúr
válasz
wolandino
#1255
üzenetére
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. -
martonx
veterán
válasz
wolandino
#1249
üzenetére
ú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 -
martonx
veterán
válasz
wolandino
#1246
üzenetére
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
válasz
martonx
#1245
üzenetére
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
válasz
wolandino
#1244
üzenetére
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
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. -
#1243
SektorFlop
aktív tag
Sk8erPeter
#1239
SektorFlop
aktív tag
válasz
Sk8erPeter
#1239
üzenetére
tényleg célszerűbb lenne, meg se fordul a fejemben ez a megoldás.
-
rum-cajsz
őstag
válasz
Fecogame
#1238
üzenetére
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.
-
#1240
Fecogame
veterán
Sk8erPeter
#1239
válasz
Sk8erPeter
#1239
üzenetére
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.
-
#1239
Sk8erPeter
nagyúr
SektorFlop
#1220
Sk8erPeter
nagyúr
válasz
SektorFlop
#1220
üzenetére
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. -
rum-cajsz
őstag
válasz
Fecogame
#1232
üzenetére
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.... -
#1225
martonx
veterán
SektorFlop
#1224
martonx
veterán
válasz
SektorFlop
#1224
üzenetére
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... -
#1223
lakisoft
veterán
SektorFlop
#1222
lakisoft
veterán
válasz
SektorFlop
#1222
üzenetére
Igazán nincs mit. Milyen adatbázis kezelőben akarod ezt megcsinálni?
-
#1221
lakisoft
veterán
SektorFlop
#1220
lakisoft
veterán
válasz
SektorFlop
#1220
üzenetére
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.
-
#1220
SektorFlop
aktív tag
SektorFlop
aktív tag
Lenne egy olyan problémám, hogy van 2 táblám.
Fizetes:
_id
FizOsszeg
FizEgyenleg
FizHonap
FizEvTerheles:
_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
válasz
lakisoft
#1218
üzenetére
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
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ő? -
#1217
Sk8erPeter
nagyúr
bpx
#1215
Sk8erPeter
nagyúr
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. -
#1215
bpx
őstag
Sk8erPeter
#1213
bpx
őstag
válasz
Sk8erPeter
#1213
üzenetére
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 -
#1214
rum-cajsz
őstag
Sk8erPeter
#1213
rum-cajsz
őstag
válasz
Sk8erPeter
#1213
üzenetére
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.
-
#1211
bpx
őstag
Sk8erPeter
#1210
bpx
őstag
válasz
Sk8erPeter
#1210
üzenetére
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 -
bpx
őstag
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
) De ugye a fenti esetben sem erre láttunk példát.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Magyarul egy adatbázisba rakni? Mi vele a problémád?
Új hozzászólás Aktív témák
- Samsung Galaxy S23 Ultra - non plus ultra
- Kamionok, fuvarozás, logisztika topik
- Asztalos klub
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Gitáros topic
- Nők, nőügyek (18+)
- A szögletes Huawei órák is lebuktak
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Energiaital topic
- Nemzetbiztonsági aggályok merültek fel a TP-Link kapcsán
- További aktív témák...
- ÁÁÁ NE NÉZD MEG! A szórakozás, és a multitasking csúcsa, Lenovo Yoga 9i //3 OLED Modell Ajánló//
- UF Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -60% i7-1360P 16/1TB Iris Xe 2,8K OLED 90Hz
- Xbox Series X 1TB - 2 kontroller + 3 játék szabadon választható
- RYZEN 7 5700X / 32GB RAM / 1TB SSD / RX 6700 XT 12GB / 750W Gold Full Modular - AMD GAMER PC
- Intel i3-9100 - 24GB RAM - Samsung 980 500GB - be quite! Pure Base 500 + 1000W Táp - MSi Z390-A PRO
- Beszámítás! Apple Mac mini 2023 M2 8GB 256GB SSD számítógép garanciával, hibátlan működéssel
- Samsung Galaxy A23 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 12 Mini 64GB, Kártyafüggetlen, 1 Év Garanciával
- MÉG ÁRCSÖKKENTÉS Lenovo Thinkcentre E73 asztali gép eladó
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RTX 4070Ti Super GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest