Windows: Cum fac...?
- Thread starter Rabbit
- Start date
Quark
Zis și Brucan
Deci: adaptorul e cam vechiut (BT V2.0 + EDR) dar cica stie A2DP. Boxa e BT V3.0 + EDR si vrea A2DP V1.2 cica. Adaptorul a venit cu Bluesoleil dar nu l-am instalat, am lasat numai stackul original al XP-ului SP3. Dumnezeu cu mila, treaba nu e importanta, e mai mult de amorul artei sa cuplez boxa aia la PC. 
De obicei nu e suficient driver-ul de XP, trebuie și softul, pentru că ăla conține drivere pentru diversele servicii mai "exotice".
Eu am o problemă cu un adaptor BT4, cam 1/3 dăți când încerc să conectez căști BT cu aptX, găsește doar serviciile "simple" hands-free, nu și Audio renderer-ul aptX. Și dacă face așa, singura soluție e reboot. Pe laptop merge de fiecare dată. Alt adaptor nu prea e o souție, pentru că e singurul pe care l-am găsit cu >10m.
Eu am o problemă cu un adaptor BT4, cam 1/3 dăți când încerc să conectez căști BT cu aptX, găsește doar serviciile "simple" hands-free, nu și Audio renderer-ul aptX. Și dacă face așa, singura soluție e reboot. Pe laptop merge de fiecare dată. Alt adaptor nu prea e o souție, pentru că e singurul pe care l-am găsit cu >10m.
Quark
Zis și Brucan
Ok, problema e XP-ul. Probabil ca daca instalez stack-ul de la Bluesoleil o sa mearga. Dar nu stiu daca "se merita" sa umplu calculatorul cu gunoiul ala de o suta de mega doar de amorul artei. 
Ma opresc pe ziua de azi, am niste cartofi pusi la prajit.
LE: s-a rezolvat dupa instalarea Bluesoleil.
Ma opresc pe ziua de azi, am niste cartofi pusi la prajit.
LE: s-a rezolvat dupa instalarea Bluesoleil.
Last edited:
Marius '95
troubleShooter
Stack-ul bluetooth din XP e de toata jena. Bluesoleil folosesc si eu pe laptop.
Nu e chiar intrebare de Windows, dar nu exista nici un topic de "programare, diverse intrebari" si nu as face unul doar pentru o chestie cu aplicabilitate extrem de restransa.
Am o problema mai ciudata: vreau sa citesc niste date dintr-o tabela din SAP si sa le scriu intr-o tabela in SQL. OK, nu chiar o tabela ci vreo 4-5, dar procesul e identic si ordinul de marime e similar, deci daca aflu cum sa o fac bine pentru o tabela pot reaplica.
Tabela are cam 100.000 de inregistrari, sa zicem. In fapt cea mai mica are cam 80.000, cea mai mare 600.000, dar nu e o diferenta foarte mare. In acest moment singurul mod in care pot citi inregistrari e prin cate un web service folosit oData. Cum SAP e inca la oData ver 2, formatele disponibile sunt XML si JSON verbose - primul are cam 100MB si al doilea cam 50MB. Intrucat riscul de a umbla cu asemenea volum e cam mare (o fac printr-un script PHP cu limita de memorie 128 MB per proces) si intrucat procesul dureaza cam mult si risc sa pice sau sa dea un timeout, citesc cate 5000 de inregistrari odata si le scriu, repet pana termin tabela - oData are notiunile de TOP si SKIP, deci e banal de facut o bucla pentru asa ceva.
Problema 1: datele care vin ajung sa le citesc cate o inregistrare (linie) odata, element cu element, si sa le scriu in SQL cu cate un INSERT INTO tabela (col1, col2...) VALUES( val1,val2...). Asta pentru ca XML-ul care vine din SAP are o structura pe care nimeni nu prea o intelege din prima ca sa citesc tot calupul de 5000 de inregistrari direct intr-un recordset, iar cele JSON nu am reusit nici macar sa le citesc in vreun fel din cauza de namespaces cretine si lipsa mea de pricepere in a lucra cu JSON si namespaces. Sugestii despre alta abordare a problemei? Aici e o discutie despre problema, rezolvarea (aproximativa, aplicabila pentru o singura inregistrare) e fix cititul element cu element: http://stackoverflow.com/questions/...element-not-parsing-correctly-with-namespaces
Problema 2: sa zicem ca am un recordset cu cele 5000 de inregistrari x Y coloane (intre 5 si 10, in functie de tabel). Cum pot sa le scriu pe toate odata in SQL? Sintaxa cu INSERT INTO tabel (col1, col2..) VALUES (val11, val12..), (val21, val22...), etc. nu merge pentru ca e limitata la 1000 de inregistrari si oricum ar rezulta un string pentru acel select de cativa mega.
In acest moment ca sa procesez un bloc de 5000 de inregistrari dureaza cam 15 secunde local pe serverul de SQL: sub 2 secunde citirea datelor prin ODATA, restul pana la 15 e scrierea in SQL cu pipeta. Problema e ca daca imi ia cate 5 minute per tabela si sunt 4-5 tabele (teoretic o pot face in paralel, practic nu stiu cat de bine o sa mearga), iar operatia ruleaza de 4 ori pe zi, actualizarea tabelelor respective ajunge sa ia o perioada semnificativa, 30-45 de minute la fiecare 6 ore. Probabil e cea mai proasta metoda de a actualiza date intre tabele din sisteme eterogene daca nu gasesc o metoda de a mari performanta cu un ordin de marime, reducand timpul total la cateva minute.
Am o problema mai ciudata: vreau sa citesc niste date dintr-o tabela din SAP si sa le scriu intr-o tabela in SQL. OK, nu chiar o tabela ci vreo 4-5, dar procesul e identic si ordinul de marime e similar, deci daca aflu cum sa o fac bine pentru o tabela pot reaplica.
Tabela are cam 100.000 de inregistrari, sa zicem. In fapt cea mai mica are cam 80.000, cea mai mare 600.000, dar nu e o diferenta foarte mare. In acest moment singurul mod in care pot citi inregistrari e prin cate un web service folosit oData. Cum SAP e inca la oData ver 2, formatele disponibile sunt XML si JSON verbose - primul are cam 100MB si al doilea cam 50MB. Intrucat riscul de a umbla cu asemenea volum e cam mare (o fac printr-un script PHP cu limita de memorie 128 MB per proces) si intrucat procesul dureaza cam mult si risc sa pice sau sa dea un timeout, citesc cate 5000 de inregistrari odata si le scriu, repet pana termin tabela - oData are notiunile de TOP si SKIP, deci e banal de facut o bucla pentru asa ceva.
Problema 1: datele care vin ajung sa le citesc cate o inregistrare (linie) odata, element cu element, si sa le scriu in SQL cu cate un INSERT INTO tabela (col1, col2...) VALUES( val1,val2...). Asta pentru ca XML-ul care vine din SAP are o structura pe care nimeni nu prea o intelege din prima ca sa citesc tot calupul de 5000 de inregistrari direct intr-un recordset, iar cele JSON nu am reusit nici macar sa le citesc in vreun fel din cauza de namespaces cretine si lipsa mea de pricepere in a lucra cu JSON si namespaces. Sugestii despre alta abordare a problemei? Aici e o discutie despre problema, rezolvarea (aproximativa, aplicabila pentru o singura inregistrare) e fix cititul element cu element: http://stackoverflow.com/questions/...element-not-parsing-correctly-with-namespaces
Problema 2: sa zicem ca am un recordset cu cele 5000 de inregistrari x Y coloane (intre 5 si 10, in functie de tabel). Cum pot sa le scriu pe toate odata in SQL? Sintaxa cu INSERT INTO tabel (col1, col2..) VALUES (val11, val12..), (val21, val22...), etc. nu merge pentru ca e limitata la 1000 de inregistrari si oricum ar rezulta un string pentru acel select de cativa mega.
In acest moment ca sa procesez un bloc de 5000 de inregistrari dureaza cam 15 secunde local pe serverul de SQL: sub 2 secunde citirea datelor prin ODATA, restul pana la 15 e scrierea in SQL cu pipeta. Problema e ca daca imi ia cate 5 minute per tabela si sunt 4-5 tabele (teoretic o pot face in paralel, practic nu stiu cat de bine o sa mearga), iar operatia ruleaza de 4 ori pe zi, actualizarea tabelelor respective ajunge sa ia o perioada semnificativa, 30-45 de minute la fiecare 6 ore. Probabil e cea mai proasta metoda de a actualiza date intre tabele din sisteme eterogene daca nu gasesc o metoda de a mari performanta cu un ordin de marime, reducand timpul total la cateva minute.
Trebuie neapărat interfața în acest mod? SAP poate rula un program abap care face table dump într-un fișier formatat (csv cu tab-uri, de exemplu), fișier care poate fi transportat pe serverul SQL și importat bulk mult mai eficient decât cu insert-uri linie cu linie.
Poate, dar nu vrea 
E politica de "custom code elimination": pentro ODATA nu e nevoie de nici un fel de cod, doar un checkbox care faca ca datele sa fie accesabile sau nu ca web service, pentru un program abap se scrie cod, cineva il suporta, cineva il migreaza si testeaza la fiecare upgrade sau modificare, avem milioane de linii de cod si cam toata lumea s-a saturat de asta: cand e o problema incepi sa cauti prin cod sa vezi ce tampenii a mai scris cate un indian care invata ABAP scriind cod de productie.
Dupa ce am platit mai mult de un miliard de dolari catre SAP pentru mirificul ERP, oamenii nu mai sunt fani neconditionati, iar eu folosesc un workaround pentru a face mai bine ceva care exista in SAP si care e jalnic, dar pentru asta imi trebuie datele respective.
E politica de "custom code elimination": pentro ODATA nu e nevoie de nici un fel de cod, doar un checkbox care faca ca datele sa fie accesabile sau nu ca web service, pentru un program abap se scrie cod, cineva il suporta, cineva il migreaza si testeaza la fiecare upgrade sau modificare, avem milioane de linii de cod si cam toata lumea s-a saturat de asta: cand e o problema incepi sa cauti prin cod sa vezi ce tampenii a mai scris cate un indian care invata ABAP scriind cod de productie.Dupa ce am platit mai mult de un miliard de dolari catre SAP pentru mirificul ERP, oamenii nu mai sunt fani neconditionati, iar eu folosesc un workaround pentru a face mai bine ceva care exista in SAP si care e jalnic, dar pentru asta imi trebuie datele respective.
Marius '95
troubleShooter
Nu merge sa scrii datele intr-un fisier temporar si sa dai LOAD DATA cand ai terminat?
Păi în condițiile astea fă ETL dacă ai cum. Accesul la date la nivel database (Oracle) e big no-no, din motive de securitate + voiding warranty + nevoia de a replica application logic pentru tabele, dacă e cazul. Accesul la date la nivel de aplicație printr-un program încorporat (SE16 sau care era) sau unul custom, rulat cu un scheduled task, iar nu e agreat, fiindcă custom code ellimination. oData îți permite doar să muți acel custom code în altă parte (PHP), nu să îl elimini. Interfață directă la date între SAP și alte sisteme n-ai de la SAP, iar de la third parties va trebui cumpărat, testat, instalat, suportat. Something's got to give.
Nu poți folosi funcționalitatea built-in din SAP pentru table dump pe baza unui scheduler, apoi transferul fișierului de pe serverul UNIX pe mașina cu MSSQL folosind TIBCO (eventual cu ceva parametri de conversie de format UNIX2DOS ca să schimbe LF-urile în CR-LF-uri pentru EOL), și apoi importul în MSSQL folosind uneltele de bulk import mai eficiente?
Sau măcar să scapi de bătaia de cap cu SAP-ul extrăgând datele cu oData într-un fișier pe care să îl poți importa bulk în SQL, că e mai eficient decât insert record-by-record.
Nu poți folosi funcționalitatea built-in din SAP pentru table dump pe baza unui scheduler, apoi transferul fișierului de pe serverul UNIX pe mașina cu MSSQL folosind TIBCO (eventual cu ceva parametri de conversie de format UNIX2DOS ca să schimbe LF-urile în CR-LF-uri pentru EOL), și apoi importul în MSSQL folosind uneltele de bulk import mai eficiente?
Sau măcar să scapi de bătaia de cap cu SAP-ul extrăgând datele cu oData într-un fișier pe care să îl poți importa bulk în SQL, că e mai eficient decât insert record-by-record.
Last edited:
Sunt mai mult de 3 indieni, dar cunostintele lor adunate nu dau cat o solutie decenta. Toti indienii sunt specialisti in SAP HANA (Business Warehouse) si SAP Gateway, mai departe am un canadian care stie bine PHP si ceva SQL, dar habar nu are de ODATA, nu am integrator si in lipsa am fost tras la sorti din drupul format de mine, eu si persoana mea. Stii, unora li se pare normal sa plateasca sume cu 6,7,8 sau 9 zerouri care companii mari, dar cand e vorba de sume cu 3,4,5 pentru niste specialisti brusc au o criza de hemoroizi si se duc sa isi aplice adanc crema. Li se spune mid-level manageri, genul de oameni care acum 25 de ani au fost IT, de vreo 20 nu au scris o linie de cod si de vreo 15 nu mai stiu mai nimic despre IT decat key words: outsourcing, strategic suppliers, internet of things, cloud (fara rain sau snow)La suma aia nu inteleg de ce-ti bati capul, ar trebui sa ai 3 indieni alocati 24/7
1. Da, dar e infinit mai ieftin sa am niste custom code in aplicatia care foloseste datele, din punctul asta de vedere nu mai e custom code, e application code: necesar atata timp cat am aplicatia in functiune, dispare o data cu ea. Custom code in SAP inseamna ca la o curatenie acum vreo 2 ani au sters cam jumatate din ce au gasit pentru ca nu era folosit de nimeni, iar din ce a ramas ei banuiau ca peste jumatate nu e folosit, dar nu puteau demonstra asta
2. Ba da, dar numai in teorie: o data cu SAP Gateway nimeni din grupul central de arhitecti nu mai accepta din principiu sa scot datele prin alta parte decat prin GW sau SAP PI; GW nu stie decat oDATA, dar e mult mai flexibil si mai usor de implementat decat PI.
3. Ca sa le scriu intr-un fisier tot linie cu linie trebuie sa o fac pentru ca ceea ce primesc pot intepreta linie cu linie. O sa incerc, dar un tip foarte istet de pe Internet mi-a dat o alta idee care, zice el, mareste performanta de vreo 15 ori cu doar 2 linii de cod in plus; din pacate indienii au dat de pamant cu serverul de test si inca nu au spalat noroiul de pe el, asa ca nu pot sa testez ideea lui promitatoare. Pe deasupra, mai avea inca una care in teste i-a dat un spor de performanta de inca vreo 10x (total: 150x), astept acum sa puna la loc cablurile cu care au incercat sa se biciuie ca sa pot testa cele doua variante. A doua suna fabulos, dar presupune modificarea metodei PDO prepare statement in PHP cu niste cod pe care abia il inteleg (nu sunt expert in PHP), probabil pot sa il adaptez dar nu stiu cui l-as da sa il suporte pe viitor.
Marius '95
troubleShooter
O alta idee (posibil cretina, ca nu m-am jucat destul cu awk) este sa faci un pipe: wget -> awk -> fisier csv, urmat de import intr-o comanda separata. Awk e cel mai greu, dar dau cu presupusul ca n-ar trebui sa iasa o comanda mai mare de 2 linii.
Laptop cu Windows 10 nu vrea să tipărească pe imprimantă USB. Troubleshooterul zice că USB Printing nu merge prin USB 3, și să folosesc un port USB 2. Bun, laptopul are 2 porturi USB 3 și 1 port USB 2, pus pe portul potrivit, chiar și prin hub ca să fie sigură treaba, și tot nimic. Imprimanta e detectată, driverele le-a instalat (am încercat și cu driverele Brother, fk 'em), statusul pare să meargă, da' nici măcar test page nu tipărește. Help?
PS: nu cred că-i belită imprimanta, că are și port de rețea și prin ăla merge ok.
PS: nu cred că-i belită imprimanta, că are și port de rețea și prin ăla merge ok.