Aventuri în dezvoltarea de software ... de David Young

Postări

Remedierea stării unui job SQL Server fără repornirea serviciilor

deep

Ieri dimineață am primit înștiințarea că o lucrare SQL Server pentru o aplicație pe care o susțin și care rulează în mod normal destul de regulat nu funcționează. Această slujbă nu a fost lansată de un program manual, ci a fost chemată din altă parte.

Am reușit să rulez manual lucrarea fără nicio problemă. Cu toate acestea, lucrarea nu a început să ruleze „automat” așa cum era de așteptat. După câteva săpături, am aflat că lucrarea a fost lansată într-o declanșare a bazei de date pe INSERT.

Secțiunea de cod care a început lucrarea arăta astfel:

Deci, acest cod ar trebui să returneze un rând doar (și să prevină executarea lucrării dacă lucrarea este deja în curs de executare. Lucrarea nu se desfășura și totuși un rând a revenit spunând că lucrarea a început cu două zile înainte și nu s-a terminat niciodată.

S-a întâmplat ca clusterul SQL Server să fie repornit exact în acel moment. Slujba părea să ruleze, dar nu a fost.

Prima soluție: reporniți agentul SQL Server. Acest lucru nu a avut niciun efect asupra tabelului de activitate sysjob.

A doua soluție: reporniți întreaga instanță SQL Server. Acest lucru nu a fost făcut, din cauza operațiunilor critice la locul de muncă.

Ce altceva s-ar putea face?

Actualizarea manuală a tabelului pentru a reflecta faptul că jobul nu mai rulează!

Rularea acestui bloc de cod introduce un timp (acum) pentru finalizarea executării lucrării și, de asemenea, trimite manual o comandă de oprire a lucrării în cazul în care lucrarea a început între timp.

După aceasta, declanșatorul a funcționat așa cum era de așteptat!

Imparte asta:

  • LinkedIn
  • Reddit
  • Facebook
  • Stare de nervozitate
  • Pinterest
  • Marea

Widgeturi în Temenos Quantum Visualizer pentru iOS și Android

În ultimele câteva săptămâni, am construit o aplicație folosind Temenos (fostul Kony) Quantum Visualizer versiunea 9. Această aplicație va fi trimisă în cele din urmă atât pe telefoanele și tabletele Apple, cât și pe cele Android, care este principalul motiv pentru care cineva ar folosi Visualizer în loc să dezvolte nativ cu XCode și Android Studio.

În teorie, codul JavaScript scris în Visualizer IDE va ​​avea ca rezultat aceeași interfață de utilizare atât pe platformele iOS, cât și pe cele Android, dar nu este întotdeauna cazul.

Pentru prima dată, am primit o eroare JavaScript reală în aplicația Android, în timp ce aplicația iOS a funcționat perfect. Aparent, Android nu este la fel de iertător atunci când lăsați accidental cuvântul cheie „nou” atunci când creați un widget - în cazul meu, un RadioButtonGroup. (Eroarea pe care am primit-o pe partea Android a fost „operațiune nevalidă: încercarea de a crea un obiect fără un cuvânt cheie„ nou ”.”)

Widgeturile RadioButtonGroup, atunci când sunt setate în modul Toggle, sunt redate diferit pe iOS și Android. Nu a fost o problemă în sine. Problema a fost că widgeturile iOS arătau bine și ocupau întreaga lățime a containerului părinte (un FlexScrollContainer), iar ecranul Android avea butoanele radio agrupate în partea stângă a ecranului.

Din orice motiv, aplicația Android a cerut ca proprietatea hExpand să fie setată la adevărat și nu a contat în versiunea iOS.

Morala poveștii: dacă interfața dvs. de utilizare arată diferit în moduri neașteptate pe o singură platformă, va necesita probabil atribute de proprietate widget detaliate în mod explicit pentru a le face să pară mai asemănătoare.

Imparte asta:

  • LinkedIn
  • Reddit
  • Facebook
  • Stare de nervozitate
  • Pinterest
  • Marea

Automatizați exportul proiectelor Primavera P6 folosind Python - Partea 2

Rezultatul părții 1 a fost o listă de fișiere XER, toate fiind într-un singur folder. Nu este clar de unde din structura proiectului de întreprindere (EPS) că a aparținut fiecare fișier.

Poate ați dori să creați o ierarhie de foldere asemănătoare cu ecranul proiectului în P6?

Mi-am modificat scriptul original Python pentru a construi o structură de dosare asemănătoare cu EPS. Nu am reușit să găsesc toate nivelurile ierarhiei în baza de date P6, dar am putut obține majoritatea nivelurilor reprezentate.

Rezultatul executării acestui script ar trebui să fie o structură de dosare cu nume similare cu titlurile din EPS. Fișierele exportate vor fi introduse în aceste foldere. Este posibil să fie necesară scăparea sau înlocuirea caracterelor ciudate din nume (așa cum se face mai sus în interogarea SQL).

Imparte asta:

  • LinkedIn
  • Reddit
  • Facebook
  • Stare de nervozitate
  • Pinterest
  • Marea

Automatizați exportul proiectelor Primavera P6 folosind Python

Cu trecerea de la o versiune veche a lui P6 (8.2) la una nouă (18.8), a trebuit să export vechile noastre proiecte din baza de date 8.2 în fișiere XER. După ce am descoperit că numărul de proiecte din vechea bază de date era de mii, am știut că va trebui să automatizez procesul dacă doresc să fiu deloc productiv pentru următoarele două săptămâni.

Oracle oferă o modalitate de export a proiectelor folosind linia de comandă. Odată ce am descoperit acest lucru, am știut că trebuie să existe o modalitate de a scrie acest scenariu pentru un număr nedefinit de proiecte.

Folosind modulul cx_Oracle al Python, m-aș putea conecta la baza de date Oracle P6 pentru a obține numele proiectului și a începe să construiesc fișierul XML necesar care să-i îndrume P6 ce să facă.

Scriptul de mai jos primește șase (6) parametri: numele de utilizator și parola bazei de date (cu ce v-ați conecta la Oracle pentru a privi baza de date), aliasul bazei de date (care trebuie să fie în TNSnames.ora sau LDAP), un nume de utilizator și o parolă pentru aplicație, și fie 0 (pentru mai multe fișiere XER), fie 1 (pentru un fișier XER pentru toate proiectele).

Nota bene: Opțiunea „one XER” nu a fost testată complet - cu excepția cazului în care baza de date este mică și/sau rulați un client P6 pe 64 de biți, probabil că veți obține o eroare de memorie folosind aceasta.

Acest script are unele erori de manipulare, astfel încât, dacă se întâlnește o eroare în procesul de export - ceea ce este aproape garantat - procesul ar trebui să înceapă din nou fără a încerca să reexporteze proiectele care au fost deja realizate sau au cauzat erori.