FORUM PER UTENTI MILLEWIN
Attenzione !
Per intervenire sul forum è necessario essere registrati e connessi.

L'Amministratore

****************************************************
“Se tu hai una mela ed io ho una mela, e ce la scambiamo, alla fine tu ed io avremo sempre una mela ciascuno.
Ma se tu hai un’idea ed io ho un’idea, e ce la scambiamo, allora avremo entrambi due idee”.

George Bernard Shaw
****************************************************

BMI in diabetici

Andare in basso

BMI in diabetici

Messaggio  lucapuccetti il Gio 13 Set 2012 - 11:23

Buongiorno faccio gentile richiesta ai colleghi di una query che estragga l'ultimo body mas index inserito nei pazienti diabetici (sia identificati come codificati che come non non codificati, se possibile) l'estrazione serve per un accordo aziendale quindi è di utilità per moltissimi colleghi.

ringrazio per l'attenzione.

cordiali saluti

Luca Puccetti Pisa

lucapuccetti
Nuovo Membro
Nuovo Membro

Messaggi : 44
Punti : 2889
Voti per importanza dei messaggi : 10
Data d'iscrizione : 02.07.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Lucio Mignone il Gio 13 Set 2012 - 13:04

lucapuccetti ha scritto:Buongiorno faccio gentile richiesta ai colleghi di una query che estragga l'ultimo body mas index inserito nei pazienti diabetici (sia identificati come codificati che come non non codificati, se possibile) l'estrazione serve per un accordo aziendale quindi è di utilità per moltissimi colleghi.

ringrazio per l'attenzione.

cordiali saluti

Luca Puccetti Pisa

l'età dei pazienti è indifferente?
Ti va bene se per diabete non codificato inseriamo glicemia superiore a 126?
Dacci qualche indicazione in più...
Lucio Mignone
Lucio Mignone
Membro Senior
Membro Senior

Messaggi : 626
Punti : 3741
Voti per importanza dei messaggi : 34
Data d'iscrizione : 20.02.11
Età : 55
Località : CAVRIGLIA (AR)

Visualizza il profilo http://comeva.altervista.org/

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Lucio Mignone il Gio 13 Set 2012 - 14:57

ciao Luca,
Piccola modifica ad una vecchia query che in questo modo dovrebbe estrarre (non sono un guru dell'sql), tramite viste, l'elenco dei pazienti di qualunque età che hanno un problema aperto che contiene la stringa DIABETE, con calcolato l'ultimo valore di BMI e ne propone una sua valutazione.
Se poi vogliamo aggiungere altri criteri per pescare qualche altro diabetico non codificato, possiamo provare (es. pz che non hanno problema diabete aperto ma: con glicemia > 126, con almeno una visita diabetologica, etc.).
Provala a me pare funzionare.



SELECT number (*) As N, cognome, nome, datavisita, datanasc, codfiscale, Years(datanasc, datavisita) As eta, sesso As __sesso__, ' ', accertamento As Tipo_di_Rilevazione, risults As Valore_BMI,

(IF ( Valore_BMI< '18.5') Then ' SottoPeso ' Else IF ( Valore_BMI Between '18.5' And '24.9') Then ' NormoPeso ' Else IF (Valore_BMI Between '25' And '29.9') Then ' Sovrappeso ' Else IF (Valore_BMI Between '30' And '34.9') Then ' Obesità 1a classe ' Else IF (Valore_BMI Between '35' And '39.9') Then ' Obesità 2a classe ' Else IF ( Valore_BMI >'39.9') Then ' Obesità 3a classe' Else ' ? ' Endif Endif Endif Endif Endif Endif) As ___Valutazione___

FROM v_accertamenti a
Where accertamento Like '%BMI%' And Not Exists
(Select a1.codice FROM v_Accertamenti a1 Where a1.codice = a.codice And a1.accertamento Like '%BMI%' And a1.datavisita > a.datavisita)

And codice IN (select y.codice from v_accertamenti y where y.problema like '%diabete%')


Group By risults, cognome, nome, datanasc, codfiscale, eta, sesso, datavisita, accertamento
Order By 2, 3, 4
Lucio Mignone
Lucio Mignone
Membro Senior
Membro Senior

Messaggi : 626
Punti : 3741
Voti per importanza dei messaggi : 34
Data d'iscrizione : 20.02.11
Età : 55
Località : CAVRIGLIA (AR)

Visualizza il profilo http://comeva.altervista.org/

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  lucapuccetti il Dom 16 Set 2012 - 13:34

Lucio Mignone ha scritto:ciao Luca,
Piccola modifica ad una vecchia query che in questo modo dovrebbe estrarre (non sono un guru dell'sql), tramite viste, l'elenco dei pazienti di qualunque età che hanno un problema aperto che contiene la stringa DIABETE, con calcolato l'ultimo valore di BMI e ne propone una sua valutazione.
Se poi vogliamo aggiungere altri criteri per pescare qualche altro diabetico non codificato, possiamo provare (es. pz che non hanno problema diabete aperto ma: con glicemia > 126, con almeno una visita diabetologica, etc.).
Provala a me pare funzionare.

Grazie Lucio, la query va benissimo, l'ho modificata in base alle mie esigenze, semplificandola:

Codice:
SELECT number (*) As N, cognome, nome,datanasc, codfiscale, Years(datanasc, datavisita) As eta, sesso As __sesso__,  datavisita, risults As Valore_BMI
FROM v_accertamenti a
Where accertamento Like '%BMI%' And Not Exists
(Select a1.codice FROM v_Accertamenti a1 Where a1.codice = a.codice And a1.accertamento Like '%BMI%' And a1.datavisita > a.datavisita)
And codice IN (select y.codice from v_accertamenti y where y.problema like '%diabete%')
Group By risults, cognome, nome, datanasc, codfiscale, eta, sesso, datavisita, accertamento
Order By 2, 3, 4

Tuttavia questa query visualizza il BMI registrato nei diabetici, servirebbe una cosa diversa: estrarre TUTTI i diabetici (sia che hanno la registrazione del BMI sia che non ce la abbiano) e visualizzare il valore del BMI in coloro in cui è stato registrato, per gli altri, cioè i diabetici cui il BMI non è stato rilevato la cella rimarrebbe vuota o con un'indicazione tipo non registrato. Così oltre a trovare il valore del BMI nei diabetici in cui è stato registrato si visualizzano i diabetici in cui il valore del BMI non è stato registrato e si provvede.

grazie saluti

Luca Pucetti Pisa

lucapuccetti
Nuovo Membro
Nuovo Membro

Messaggi : 44
Punti : 2889
Voti per importanza dei messaggi : 10
Data d'iscrizione : 02.07.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Lun 17 Set 2012 - 20:07

Questa è un pò fuori dalle regole canoniche , ma funziona (almeno nel mio caso); certo... estrarre i Diabetici senza ricorrere alla codifica porta a risultati non veritieri... (nel mio caso estrae come diabetici anche un diabete insipido, un diabete renale, 3 diabetici sospetti che non avevo codificato appunto perchè non ne ero sicuro-e che poi si è dimostrato non esserlo- ecc

-------------------------------------------------

SELECT p.cognome,p.nome, p.datanasc, (year(data)-year(p.datanasc)) eta,

( SELECT Max(a.data_open) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
and a.ac_val > '' AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)) ) ) data,

( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609' AND ac_val > '' AND a.data_open=data ) Last_BMI

FROM V_PAZIENTI p
Where EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb. nome_pbl like '%diabete%' )

Order By 1, 2
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Mar 18 Set 2012 - 9:28

Mi era sfuggito che il calcolo dell'età dei paz è impreciso; sostituisci con :

DATEDIFF ( yy, p.datanasc,data ) eta,
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Cervino il Mar 18 Set 2012 - 15:03

Ciao Leo ,
la formula String(Cast(x.data_open As Text) calcola erroneamente l' anno se la data è all' infuori di un determinato arco temporale ; dovendo estrarre per l' ASL le date in formato : aaaammdd oppure aaaa/mm/dd ( piu' intuitivo ) ,
per il momento utilizzo la seguente formula ( per la data di nascita ad es. ) :

Cast( If p.sesso Like 'M' Then Substr( p.codice_fiscale, 6, 4) || Substr( n.pa_uslcode, 3, 4) Else Substr( n.pa_uslcode, 3, 4) || Substr( p.codice_fiscale, 6, 4) Endif As Char (12)) As cod_reg,
Cast( Cast( Year( p.nascita) As Char(4)) + '/' + If Length( Month( p.nascita))=1 Then '0' +
Cast( Month( p.nascita) As Char(1)) Else Cast( Month( p.nascita) As Char(2)) Endif + '/' + If Length( Day( p.nascita))=1 Then '0' +
Cast( Day( p.nascita) As Char(1)) Else Cast( Day( p.nascita) As Char(2)) Endif As Char(15)) As nascita,


Chiedo agli Esperti del Forum :
1) se conoscono eventualmente, un metodo piu' semplice di formattazione delle date, in quanto la formula sopra evidenziata, ripetuta in numerose subquery, blocca piu' facilmente il motore di accesso al mille.db ( Adaptive Server Anywhere Database Engine ) : dbeng7.exe *32; il numero massimo di colonne accettate scende da 62 a 58-60 e di conseguenza bisogna eseguire una seconda estrazione per ottenere i 2-4 rimanenti campi ( ovviamente una seccatura per un elevato numero di Colleghi )

2) un eventuale suggerimento per semplificare la subquery :

If (Select Cast( Case When Locate(a.ac_val,'%') > 0 Then Left(a.ac_val, Locate(a.ac_val,'%')-3) + Substring(a.ac_val, Locate(a.ac_val,'%')-1, 1) When Left(a.ac_val, 2) = 'No' Then 0 Else 0 End As Int)
From cart_accert a Where a.codice=p.codice And a.ac_des like 'Rischio%Card%ISS%' And
a.ac_val Is Not Null And Not Exists (Select a1.codice From cart_accert a1 Where a1.codice =
a.codice And a1.ac_des Like 'Risch%Card%Vascol%ISS%' And (a1.data_open>a.data_open
Or (a1.data_open = a.data_open And a1.rowid>a.rowid)) And a1.ac_val Is Not Null)
And a.data_open Between data_query-1825 And data_query ) Is Null Then 0 Else
(Select Cast( Case When Locate(a.ac_val,'%') > 0 Then Left(a.ac_val, Locate(a.ac_val,'%')-3) + Substring(a.ac_val,
Locate(a.ac_val,'%')-1, 1) When Left(a.ac_val, 2) = 'No' Then 0 Else 0 End As Int)
From cart_accert a Where a.codice=p.codice And a.ac_des like 'Rischio%Card%ISS%' And
a.ac_val Is Not Null And Not Exists (Select a1.codice From cart_accert a1 Where a1.codice =
a.codice And a1.ac_des Like 'Risch%Card%Vascol%ISS%' And (a1.data_open>a.data_open
Or (a1.data_open = a.data_open And a1.rowid>a.rowid)) And a1.ac_val Is Not Null)
And a.data_open Between data_query-1825 And data_query ) Endif
_RCV_,


l' esempio è riferito al Rischio CardioVascolare ; la formattazione richiesta è :
Intero del valore calcolato moltiplicato x 10 oppure 0 = nessun dato registrato ;

perchè la condizione iniziale < ... Else 0 End ..> non viene acettata , di conseguenza bisogna
aggiungere una clausola apparentemente ridondante ( che appesantisce la query ? )

Grazie per i suggerimenti
Un saluto da Sergio , Orzivecchi



draleo83 ha scritto:Questa è un pò fuori dalle regole canoniche , ma funziona (almeno nel mio caso); certo... estrarre i Diabetici senza ricorrere alla codifica porta a risultati non veritieri... (nel mio caso estrae come diabetici anche un diabete insipido, un diabete renale, 3 diabetici sospetti che non avevo codificato appunto perchè non ne ero sicuro-e che poi si è dimostrato non esserlo- ecc

-------------------------------------------------

SELECT p.cognome,p.nome, p.datanasc, (year(data)-year(p.datanasc)) eta,

( SELECT Max(a.data_open) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
and a.ac_val > '' AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)) ) ) data,

( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609' AND ac_val > '' AND a.data_open=data ) Last_BMI

FROM V_PAZIENTI p
Where EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb. nome_pbl like '%diabete%' )

Order By 1, 2

Cervino
Membro Junior
Membro Junior

Messaggi : 234
Punti : 3196
Voti per importanza dei messaggi : 19
Data d'iscrizione : 03.03.11
Età : 64
Località : Orzivecchi (BS)

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Mar 18 Set 2012 - 19:35

Francamente non trovo l’errore.

Infatti se x.dataopen fosse : 12/06/12 e x.time_last fosse : 12/06/12 10.01.43,5

La formula Cast(x.data_open As Text) restituisce regolarmente: 2012-06-12

La formula CAST(x.time_last AS TEXT) restituisce regolarmente :2012-06-12 10:01:43.500

la formula string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) restituisce

2012-06-122012-06-12 10:01:43.500000



TRATTASI COMUNQUE DI UN PERFEZIONISMO che ho voluto sperimentare (mi annoia fare sempre le stesse cose ed usare le stesse procedure):

*credo* potrebbe essere un modo più preciso per estrarre l’ultima data dell’accertamento , e per evitare che l’espressione che viene più usata allo scopo

x.data_open >a.data_open

possa mandare in tilt l’intera query (quando lo stesso accertamento è ripetuto nella stessa data può capitare che la query restituisca 0 pazienti)

Invece si potrebbe obiettare che la query non permette di scegliere il periodo da considerare per l’estrazione del BMI

Ma la richiesta del collega non parlava di periodi e quindi ho preferito esaminare tutto l’archivio

Invece se si volesse scegliere, di volta in volta il periodo da esaminare ,le 2 subquery andrebbero impostate sulle viste e non sugli archivi(come è ora). Ma si può fare facilmente (anzi la query sarebbe anche più facile)



Per quanto riguarda il tuo problema, non ho capito cosa vuoi fare. se ti spieghi meglio, insieme ai tanti colleghi esperti, si potrebbe vedere se esita una possibile soluzione
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Cervino il Mer 19 Set 2012 - 0:22

Scusami Leo hai ragione la formula funziona; avevo una discrepanza di date dell' inizio del problema Diabete in MW, per alcuni pazienti fra la cartella paz_pbl e cart_problemi e grazie al Tuo suggerimento, ho riallineato le date ,
comunque non ho compreso la differenza fra :

String( Cast (data_open As Text )) e Cast (data_open As Text ) o Cast (data_open As Char(16))
al fine di restringere la larghezza delle colonne estratte nella finestra di MU .

Il problema è il seguente : in una query con il limite massimo di colonne accettato in W7 a 64 bit, viene richiesta una specifica formattazione di numerosi campi, diversa da quella fornita di default in MU .
Inserendo ad esempio le due formule sopra riportate il motore di accesso al mille.db ( Adaptive Server Anywhere Database Engine ) : dbeng7.exe *32 si blocca; di conseguenza devo chiudere manualmente MU e/o MW (se aperto) e poi tramite task manager anche dbeng7.exe *32 per poter riavviare MU e/o MW e spesso con la cancellazione della query che era in fase di test; rieseguendo la query con un numero minore di colonne ( 3), il problema non si ripresenta .
Di conseguenza bisogna ricorrere ad una doppia estrazione per aggiungere le colonne mancanti;
un' eventuale semplificazione delle formule potrebbe forse risolvere il problema ?
Tuttavia ho provato a semplificare la formula di formattazione della data in base al tuo suggerimento ( utilizzando le formule :

String( Cast (data_open As Text )) o Cast (data_open As Text ) o Cast (data_open As Char(16))

ma il risultato non è cambiato; quindi non dovrebbero esseri i campi data a determinare il blocco del dbeng7.exe *32 .

La formattazione dei risultati degli accertamento non è univoca ;
in genere se il campo è nullo viene richiesto di inserire il valore 0 invece
in caso di eventuale risultato decimale : Intero del valore calcolato moltiplicato x 100 ( o x 10 ) oppure 0 = nessun dato registrato .

ad esempio la subquery :

(Select Case When Locate(a.ac_val,',') > 0 Then Cast( (Left(a.ac_val, Locate(a.ac_val,',')-1) + Substring(a.ac_val, Locate(a.ac_val,',')+1, 1))*10 As Int) When a.ac_val >0 Then Cast( a.ac_Val*100 As Int) When a.ac_val Is Null Then Cast( 0 As Int) End From cart_accert a Where a.codice=p.codice And a.ac_des Like 'Creatinina' And a.ac_val Is Not Null And Not Exists (Select a1.codice From cart_accert a1 Where a1.codice = a.codice And a1.ac_des Like 'Creatinina' And (a1.data_open > a.data_open Or (a1.data_open = a.data_open And a1.rowid>a.rowid)) And a1.ac_val Is Not Null ) And a.data_open Between data_query-8000 And data_query )
_creatinina_,


in caso di campo nullo non aggiunge lo 0 richiesto e devo ricorrere alla formula :

If (Select Cast( Case When Locate(a.ac_val,',') > 0 Then (Left(a.ac_val, Locate(a.ac_val,',')-1) + Substring(a.ac_val, Locate(a.ac_val,',')+1, 1))*10 When Length( a.ac_val) > 0 Then a.ac_Val*100
Else 0 End As Int) From cart_accert a Where a.codice=p.codice And a.ac_des Like 'Creatinina' And a.ac_val Is Not Null And Not Exists (Select a1.codice From cart_accert a1 Where a1.codice = a.codice And a1.ac_des Like 'Creatinina' And (a1.data_open > a.data_open Or (a1.data_open = a.data_open And a1.rowid>a.rowid)) And a1.ac_val Is Not Null ) And a.data_open Between data_query-8000 And data_query ) Is Null Then 0 Else (Select Cast( Case When Locate(a.ac_val,',') > 0 Then (Left(a.ac_val, Locate(a.ac_val,',')-1) + Substring(a.ac_val, Locate(a.ac_val,',')+1, 1))*10 When Length( a.ac_val) > 0 Then a.ac_Val*100 Else 0 End As Int) From cart_accert a Where a.codice=p.codice And a.ac_des Like 'Creatinina' And a.ac_val Is Not Null And Not Exists (Select a1.codice From cart_accert a1 Where a1.codice = a.codice And a1.ac_des Like 'Creatinina' And (a1.data_open > a.data_open Or (a1.data_open = a.data_open And a1.rowid>a.rowid)) And a1.ac_val Is Not Null )
And a.data_open Between data_query-8000 And data_query ) Endif
_creatinina_,

per ottenere le formattazione richiesta.

E' possibile eventualmente semplificare la formula, in modo da non dover ridurre il numero di colonne estratte dalla singola query ?

Ti saluto , grazie per eventuali suggerimenti Sergio





draleo83 ha scritto:Francamente non trovo l’errore.

Infatti se x.dataopen fosse : 12/06/12 e x.time_last fosse : 12/06/12 10.01.43,5

La formula Cast(x.data_open As Text) restituisce regolarmente: 2012-06-12

La formula CAST(x.time_last AS TEXT) restituisce regolarmente :2012-06-12 10:01:43.500

la formula string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) restituisce

2012-06-122012-06-12 10:01:43.500000



TRATTASI COMUNQUE DI UN PERFEZIONISMO che ho voluto sperimentare (mi annoia fare sempre le stesse cose ed usare le stesse procedure):

*credo* potrebbe essere un modo più preciso per estrarre l’ultima data dell’accertamento , e per evitare che l’espressione che viene più usata allo scopo

x.data_open >a.data_open

possa mandare in tilt l’intera query (quando lo stesso accertamento è ripetuto nella stessa data può capitare che la query restituisca 0 pazienti)

Invece si potrebbe obiettare che la query non permette di scegliere il periodo da considerare per l’estrazione del BMI

Ma la richiesta del collega non parlava di periodi e quindi ho preferito esaminare tutto l’archivio

Invece se si volesse scegliere, di volta in volta il periodo da esaminare ,le 2 subquery andrebbero impostate sulle viste e non sugli archivi(come è ora). Ma si può fare facilmente (anzi la query sarebbe anche più facile)



Per quanto riguarda il tuo problema, non ho capito cosa vuoi fare. se ti spieghi meglio, insieme ai tanti colleghi esperti, si potrebbe vedere se esita una possibile soluzione

Cervino
Membro Junior
Membro Junior

Messaggi : 234
Punti : 3196
Voti per importanza dei messaggi : 19
Data d'iscrizione : 03.03.11
Età : 64
Località : Orzivecchi (BS)

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Admin il Mer 19 Set 2012 - 19:26

draleo83 ha scritto: Francamente non trovo l’errore.

Infatti se x.dataopen fosse : 12/06/12 e x.time_last fosse : 12/06/12 10.01.43,5

La formula Cast(x.data_open As Text) restituisce regolarmente: 2012-06-12

La formula CAST(x.time_last AS TEXT) restituisce regolarmente :2012-06-12 10:01:43.500

la formula string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) restituisce

2012-06-122012-06-12 10:01:43.500000

RATTASI COMUNQUE DI UN PERFEZIONISMO che ho voluto sperimentare (mi annoia fare sempre le stesse cose ed usare le stesse procedure):

*credo* potrebbe essere un modo più preciso per estrarre l’ultima data dell’accertamento , e per evitare che l’espressione che viene più usata allo scopo

x.data_open >a.data_open

possa mandare in tilt l’intera query (quando lo stesso accertamento è ripetuto nella stessa data può capitare che la query restituisca 0 pazienti)


Caro Leonardo, non credo che usare Time Last possa rendere più precisa la data più recente di un accertamento. Se osservi la tabella seguente:





ac_des



ac_val



data_open



data_upd



time_last



rowid



ora
GLICEMIA
94
01/09/10
29/09/10 19:24:18,27
29/09/10 19:24:18,27
4=.<;DA
09:15
GLICEMIA
29/11/10
29/11/10 09:12:28,359
29/11/10 20:31:30,06
9=!$)TS
09:11
GLICEMIA
111
19/01/11
02/02/11 20:42:19,724
02/02/11 20:42:19,724
C=@VRIH
13:17
GLICEMIA
24/03/11
24/03/11 12:15:56,97
24/03/11 12:15:56,97
1=$[SP+
12:10
GLICEMIA
111
25/05/11
01/06/11 13:11:37,88
03/06/11 09:02:21,921
N:1}1K{
09:51
GLICEMIA
99
29/06/11
13/07/11 17:49:20,786
13/07/11 17:49:20,786
5:3N*?D
00:02
GLICEMIA
95
07/09/11
15/09/11 00:04:53,004
15/09/11 00:04:53,004
1:6;0>]
17:07
GLICEMIA
106
18/10/11
26/10/11 12:52:42,387
29/10/11 15:15:56,865
Q:8?TQ)
21:32
GLICEMIA
103
24/01/12
08/02/12 15:04:48,215
08/02/12 15:04:48,215
2:D}{+V
22:51
GLICEMIA
93
06/06/12
20/06/12 16:11:28,897
20/06/12 16:11:28,897
P:KF#!W
16:17
GLICEMIA
90
22/08/12
12/09/12 15:58:40,341
12/09/12 15:58:40,341
Y:O-]EB
13:20


la colonna Time Last non ha niente a che vedere con il momento in cui è stato effettuato l'accertamento. Credo che se proprio si vuole affinare la precisione conviene fare riferimento alla colonna "ora" che si riferisce al momento della scrittura dell'accertamento.

_________________
L'Amministratore
Giuseppe Blasio
Admin
Admin
Admin
Admin

Messaggi : 525
Punti : 3605
Voti per importanza dei messaggi : 85
Data d'iscrizione : 20.02.11
Località : CASERTA

Visualizza il profilo http://utentimillewin.forumattivo.it

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Mer 19 Set 2012 - 20:05

Admin ha scritto:
Caro Leonardo, non credo che usare Time Last possa rendere più precisa la data più recente: se osservi la tabella seguente:la colonna Time Last non ha niente a che vedere con il momento in cui è stato effettuato l'accertamento. Credo che se proprio si vuole affinare la precisione conviene fare riferimento alla colonna ora che si riferisce al momento della scrittura dell'accertamento.

L'idea di usare la stringa che unisce data_open+time_last mi è venuta per scegliere il più recente, tra 2 accertamenti uguali,inseriti per errore allo stesso paz nella stessa data. Visto che non posso usare data open (perchè riporta la stessa data per entrambi gli accertamenti), ho provato ad usare ANCHE time last (in più rispetto al solo data_open) che ,riportando anche l'ora e i secondi, potrebbe - in teoria-essere adatta. infatti time_last non può essere uguale per entrambi gli accertamenti (sicuramente uno è stato scritto prima e l'altro qualche secondo o minuto dopo). Ho verificato che Sicuramente non porta danni; invece per quanto riguarda l'efficacia del ragionamento va verificata sul campo facendo parecche apposite verifiche e controverifiche (che però non ho ancora trovato il tempo di fare). D'altra parte la sua eventuale utilità riguarderebbe solo casi sporadici. In attesa di approfondire meglio ,mi accontento, per ora, che non porti danni.

Sicuramente se vi fosse una colonna che riportasse l'ora e i secondi (avere solo l'ora in cui è stato precritto l'accertamento non basterebbe), sarebbe meglio; però non mi sembra che ci siano colonne del genere nell'archivio accertamenti (ma non avendo al momendo sottomano la sequenza dei campi di tale archivio non posso giurarci)

Ciao

draleo
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Admin il Mer 19 Set 2012 - 20:21

draleo83 ha scritto:
Admin ha scritto:
Caro Leonardo, non credo che usare Time Last possa rendere più precisa la data più recente: se osservi la tabella seguente:la colonna Time Last non ha niente a che vedere con il momento in cui è stato effettuato l'accertamento. Credo che se proprio si vuole affinare la precisione conviene fare riferimento alla colonna ora che si riferisce al momento della scrittura dell'accertamento.

L'idea di usare la stringa che unisce data_open+time_last mi è venuta per scegliere il più recente, tra 2 accertamenti uguali,inseriti per errore allo stesso paz nella stessa data. Visto che non posso usare data open (perchè riporta la stessa data per entrambi gli accertamenti), ho provato ad usare ANCHE time last (in più rispetto al solo data_open) che ,riportando anche l'ora e i secondi, potrebbe - in teoria-essere adatta. infatti time_last non può essere uguale per entrambi gli accertamenti (sicuramente uno è stato scritto prima e l'altro qualche secondo o minuto dopo). Ho verificato che Sicuramente non porta danni; invece per quanto riguarda l'efficacia del ragionamento va verificata sul campo facendo parecche apposite verifiche e controverifiche (che però non ho ancora trovato il tempo di fare). D'altra parte la sua eventuale utilità riguarderebbe solo casi sporadici. In attesa di approfondire meglio ,mi accontento, per ora, che non porti danni.

Sicuramente se vi fosse una colonna che riportasse l'ora e i secondi (avere solo l'ora in cui è stato precritto l'accertamento non basterebbe), sarebbe meglio; però non mi sembra che ci siano colonne del genere nell'archivio accertamenti (ma non avendo al momendo sottomano la sequenza dei campi di tale archivio non posso giurarci)

Ciao

draleo

In realtà il campo ora differenzia ora e minuti per cui credo che sia sufficiente. Tuttavia il tentativo, apprezzabile, di aumentare la precisione dell'estrazione credo che sia inefficace, inutile ed a volte controproducente per una serie di motivi:

-non credo che con la stringa composta il confronto venga effettivamente effettuato. Se al posto di time_last si usa data_upd o ora, o si usa solo data_open, il risultato restituito è sempre lo stesso nonostante i valori siano diversi.

- il risultato della colonna "Data" fa comunque solo riferimento a data_open e non anche a time last e di conseguenza anche il risultato della successiva colonna fa riferimento solo a data_open

- anche se si estrae tenendo conto solo di data_open il sistema considera l'ultimo risultato inserito o modificato in quel giorno, quindi quello che si vorrebbe con l'uso della stringa.

Piuttosto il problema potrebbe porsi in quei casi in cui si prescrivono più esami lo stesso giorno anche se verranno eseguiti in giorni diversi nell'arco magari di un mese o più (ad es. 4 PT sulla stessa ricetta). In questo caso sarebbe utile usare la data di esecuzione dell'esame e non quella di prescrizione né di inserimento dei dati. Ma quanti memorizzano la data di esecuzione ? Io mai. In fondo, a mio giudizio, si tratta di una ricerca della perfezione che ci complica la vita inutilmente, però se si riescono a standardizzare varie modalità di uso dei dati ben venga.

_________________
L'Amministratore
Giuseppe Blasio
Admin
Admin
Admin
Admin

Messaggi : 525
Punti : 3605
Voti per importanza dei messaggi : 85
Data d'iscrizione : 20.02.11
Località : CASERTA

Visualizza il profilo http://utentimillewin.forumattivo.it

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Gio 20 Set 2012 - 20:16

Cervino ha scritto:.
Il problema è il seguente :.............Di conseguenza bisogna ricorrere ad una doppia estrazione per aggiungere le colonne mancanti;
un' eventuale semplificazione delle formule potrebbe forse risolvere il problema ?
.................... in caso di campo nullo non aggiunge lo 0 richiesto e devo ricorrere alla formula :

Caro Sergio, andiamo per ordine:

1)formati delle date: non ho capito qual è il formato che serve a te. Quelle che io utilizzo di più sono:

cast(today()as text) restituisce 2012-09-20

cast(today()as char(16)) idem ,in più si può impostare la larghezza della colonna che quì è 16

CONVERT(varchar(16), today(), 103), restituisce gg/mm/ aaaa cioè: 20/09/2012

CONVERT(varchar(10), today(), 103), come sopra ma con larghezza 10

CONVERT(varchar, today(), 105), restituisce gg-mm- aaaa cioè 20-09-2012, con larghezza standard

CONVERT(VARCHAR(16), today(), 105), come sopra, ma la colonna è larga 16

Se queste non fanno al tuo caso, puoi trovarne a dozzine al sito

http://msdn.microsoft.com/it-it/library/ms187928.aspx

sono per MySql della microsoft, ma nell’80% dei casi vanno bene anche per Milleutilità

2) Formato del risultato dell’accertamento.

E’ un vecchio problema, soprattutto con i num decimali es creatinina,BMI,Hbglicata ecc , In cui molti (tra cui io),spesso utilizzano come separatore indistintamente sia il punto che la virgola. E’ anche un problema che personalmente non mi tocca, perché io utilizzo quasi sempre Excel per le mie estrazioni. Estraggo i valori come sono sono e con Excel poi posso trasformarli facilmente in numero, con il formato preferito. Dalla tua risposta mi sembra di aver capito che tu sei costretto ad aggiungere una lunga serie di comandi (quelli da te segnalati in colore blu) per mettere lo 0 quando il risultato è nullo e questa eccessiva lunghezza della procedura manda in tilt tutta la query

Soluzioni ?

Ho modificato la mia query fatta per il collega che estareva l’ultimo BMI dei diabetici e la riporto sotto. Essa Estrae il valore del BMI in formato decimale e se il valore è nullo mette 0.

Naturalmente per altri accertamenti (es creatinina) vanno cambiati i riferimenti, ma la sostanza non cambia. Inoltre ho continuato ad utilizzare l’espressione CAST(a.time_last AS TEXT) perché , mi sembra che la sua efficacia non sia inferiore alle soluzioni tradizionali riportate da Giuseppe; ma è solo un particolare che dipende dai gusti: nulla toglie che tu possa usare altre espressioni equivalenti

Infine alcune considerazioni personali

Credo che il problema da te riscontrato NON sia dovuto al formato delle date o dal num e/o larghezza delle colonne, e/o dal formato dei dati , ma al fatto che l’SQL (soprattutto quello di MW) ha dei limiti:quando la lunghezza e/o complessità delle query superano un certo limite (che non conosco), va in tilt. E’ come la 500: se la si utilizza per una normale attività quotidiana è una buona auto . Si può anche potenziarne le prestazioni, ricorrendo a 1000 geniali artifici -ai miei tempi facevano la 500 abarth - ma rimarrà sempre una 500 e non potrà mai raggiungere le prestazioni di un’auto di fascia superiore .

Per cui se tu non riuscissi a risolvere il problema, fa capire ai colleghi che utilizzeranno la procedura che di fronte ad estrazioni particolarmente complesse (sempre indispensabili ?), la query deve essere spezzata e che occorre un po’ di lavoro anche da parte loro- visto che sono loro i beneficiari-, nel ricongiungere poi 2 o più parti dei risultati

Tra l’altro io non farei neanche tutto questo lavoro per un problema di formati : il formato del dato è un aspetto secondario : è solo il modo in cui questo appare a video; importante non è il formato del dato , ma che il dato sia corretto ( se poi vogliono altri formati, non credo sia un gran problema per loro utilizzare le manine per copiare i 30-40 valori forniti dalla tua query nel formato da loro preferito )

Spero che nella query ci sia qualche spunto utile per risolvere il tuo problema (che tu naturalmente dovrai modificare per adattarlo alle tue esigenze: ma la capacità non ti manca, anzi riesci a fare cose complicatissime con l'SQL di Milleutilità che molti cosidetti professionisti dovrebbero venire a scuola da te)

ciao

Leonardo

----------------------------------------------------------------------------------

SELECT p.cognome,p.nome, p.sesso,DATEDIFF ( yy, p.datanasc,today() ) eta

,CAST(
IF ( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)))) IS NULL THEN 0 ELSE
( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)))) ENDIF
AS DEC(5,2)) BMI


FROM V_PAZIENTI p
Where EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb.cp_code like '250%' )


Order By 1,2
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Ven 21 Set 2012 - 11:25

Scusa Segio, ma solo stamane mi sono accorto che la soluzione che ti ho proposto, tu l'avevi già asperimentata e non aveva risolto il tuo problema. Quindi...ciccia

Occorrerà pensarci meglio (ma temo che sia irrisolvibile)

Leonardo
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Cervino il Sab 22 Set 2012 - 12:36

Grazie Leo
per il suggerimento su come utilizzare la funzione Convert , che conoscevo vagamente :

per il formato richiesto serve : Convert( VarChar(15), p.nascita, 111)

anche se personalmente preferisco : Convert( VarChar(15), p.nascita, 112)

Ti chiedo , approffitando della tua disponibilità e gentilezza un altro consiglio :

se nella query inserisco il campo :

Convert( VarChar(15) , '2012-12-31' , 112 ) As data_query, oppure Convert( VarChar(15) , Today(), 112 ) As data_query,

al fine di avere i campi data omogenei e numerose subquery terminano con la clausola :

...And a.data_open Between data_query-1825 And data_query )

compare, al comando Esegui , il messaggio : ... Cannot convert numeric to timestamp

mentre viene acettato il campo : Cast( '2012-12-31' As Date) As data_query,

Non è comunque un problema rilevante ma se per caso conosci una semplice .. per Te soluzione , Ti ringrazio .

Concordo perfettamente con le Tue considerazioni sull' SQL di MW ; tuttavia la 500 non è ancora una macchina d' epoca per la softhouse che lo gestisce ed aggiorna e continua a ritenere MW molto performante e pertanto Ci richiede adeguato compenso .

Il Tuo suggerimento per convertire i campi null in valore 0, è altrettanto efficace, forse piu' semplice rispetto al mio;
comunque la situazione è complessa in quanto i valori decimali vanno convertiti in interi, moltiplicando *10 o *100 : quando il campo è disomogeneo ( interi, decimali con virgola o punto e con uno o due cifre, decimali senza virgola e punto, errori di ortografia, ecc. mentre il formato del BMI è uniforme ad esempio ), scrivere una subquery light diventa ... arduo, almeno per me e forse sarà opportuno
rinunciare ad una delle opzioni di formattazione ottimale richieste.

Ti saluto e grazie , Sergio


draleo83 ha scritto:
Caro Sergio, andiamo per ordine:

1)formati delle date: non ho capito qual è il formato che serve a te. Quelle che io utilizzo di più sono:

cast(today()as text) restituisce 2012-09-20

cast(today()as char(16)) idem ,in più si può impostare la larghezza della colonna che quì è 16

CONVERT(varchar(16), today(), 103), restituisce gg/mm/ aaaa cioè: 20/09/2012

CONVERT(varchar(10), today(), 103), come sopra ma con larghezza 10

CONVERT(varchar, today(), 105), restituisce gg-mm- aaaa cioè 20-09-2012, con larghezza standard

CONVERT(VARCHAR(16), today(), 105), come sopra, ma la colonna è larga 16

Se queste non fanno al tuo caso, puoi trovarne a dozzine al sito

http://msdn.microsoft.com/it-it/library/ms187928.aspx

sono per MySql della microsoft, ma nell’80% dei casi vanno bene anche per Milleutilità

2) Formato del risultato dell’accertamento.

E’ un vecchio problema, soprattutto con i num decimali es creatinina,BMI,Hbglicata ecc , In cui molti (tra cui io),spesso utilizzano come separatore indistintamente sia il punto che la virgola. E’ anche un problema che personalmente non mi tocca, perché io utilizzo quasi sempre Excel per le mie estrazioni. Estraggo i valori come sono sono e con Excel poi posso trasformarli facilmente in numero, con il formato preferito. Dalla tua risposta mi sembra di aver capito che tu sei costretto ad aggiungere una lunga serie di comandi (quelli da te segnalati in colore blu) per mettere lo 0 quando il risultato è nullo e questa eccessiva lunghezza della procedura manda in tilt tutta la query

Soluzioni ?

Ho modificato la mia query fatta per il collega che estareva l’ultimo BMI dei diabetici e la riporto sotto. Essa Estrae il valore del BMI in formato decimale e se il valore è nullo mette 0.

Naturalmente per altri accertamenti (es creatinina) vanno cambiati i riferimenti, ma la sostanza non cambia. Inoltre ho continuato ad utilizzare l’espressione CAST(a.time_last AS TEXT) perché , mi sembra che la sua efficacia non sia inferiore alle soluzioni tradizionali riportate da Giuseppe; ma è solo un particolare che dipende dai gusti: nulla toglie che tu possa usare altre espressioni equivalenti

Infine alcune considerazioni personali

Credo che il problema da te riscontrato NON sia dovuto al formato delle date o dal num e/o larghezza delle colonne, e/o dal formato dei dati , ma al fatto che l’SQL (soprattutto quello di MW) ha dei limiti:quando la lunghezza e/o complessità delle query superano un certo limite (che non conosco), va in tilt. E’ come la 500: se la si utilizza per una normale attività quotidiana è una buona auto . Si può anche potenziarne le prestazioni, ricorrendo a 1000 geniali artifici -ai miei tempi facevano la 500 abarth - ma rimarrà sempre una 500 e non potrà mai raggiungere le prestazioni di un’auto di fascia superiore .

Per cui se tu non riuscissi a risolvere il problema, fa capire ai colleghi che utilizzeranno la procedura che di fronte ad estrazioni particolarmente complesse (sempre indispensabili ?), la query deve essere spezzata e che occorre un po’ di lavoro anche da parte loro- visto che sono loro i beneficiari-, nel ricongiungere poi 2 o più parti dei risultati

Tra l’altro io non farei neanche tutto questo lavoro per un problema di formati : il formato del dato è un aspetto secondario : è solo il modo in cui questo appare a video; importante non è il formato del dato , ma che il dato sia corretto ( se poi vogliono altri formati, non credo sia un gran problema per loro utilizzare le manine per copiare i 30-40 valori forniti dalla tua query nel formato da loro preferito )

Spero che nella query ci sia qualche spunto utile per risolvere il tuo problema (che tu naturalmente dovrai modificare per adattarlo alle tue esigenze: ma la capacità non ti manca, anzi riesci a fare cose complicatissime con l'SQL di Milleutilità che molti cosidetti professionisti dovrebbero venire a scuola da te)

ciao

Leonardo

----------------------------------------------------------------------------------

SELECT p.cognome,p.nome, p.sesso,DATEDIFF ( yy, p.datanasc,today() ) eta

,CAST(
IF ( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)))) IS NULL THEN 0 ELSE
( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string( CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)))) ENDIF
AS DEC(5,2)) BMI


FROM V_PAZIENTI p
Where EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb.cp_code like '250%' )


Order By 1,2

Cervino
Membro Junior
Membro Junior

Messaggi : 234
Punti : 3196
Voti per importanza dei messaggi : 19
Data d'iscrizione : 03.03.11
Età : 64
Località : Orzivecchi (BS)

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Sab 22 Set 2012 - 20:02

Cervino ha scritto:al fine di avere i campi data omogenei e numerose subquery terminano con la clausola :

...And a.data_open Between data_query-1825 And data_query )

compare, al comando Esegui , il messaggio : ... Cannot convert numeric to timestamp

mentre viene acettato il campo : Cast( '2012-12-31' As Date) As data_query,


Forse c’è qualcosa che mi sfugge, perché la soluzione mi appare semplice (ma se fosse semplice tu l’avresti già risolta da solo e temo forse di essere io a non aver capito il problema); comunque

Convert( VarChar(15) , '2012-12-31' , 112 ) As data_query è un campo testo, e quindi quando cerchi di sottrarre ad un campo testo il numero 1825

Ti segnala l’errore ... Cannot convert…..
Mentre Cast( '2012-12-31' As Date) As data_query, è un campo data e puoi tranquillamente sottrarre 1825

Quindi per far funzionare il tutto Devi fare una doppia conversione sulla data query

cast(Convert(VarChar(15),'2012-12-31',112) as date) as data_query.

Così dovrebbe funzionare anche

And a.data_open Between data_query-1825 And data_query )

Attenzione però (ed è qui la cosa che mi sfugge): la query funziona bene solo se anche data_open è in formato data,ma se tu gli hai dato un altro formato (che io ignoro) allora …tutto va riconsiderato. Inoltre le date sopradette appariranno in formato italiano; se tu le volessi in altro formato dovresti fare una ulteriore conversione.


Cervino ha scritto:comunque la situazione è complessa in quanto i valori decimali vanno convertiti in interi, moltiplicando *10 o *100 : quando il campo è disomogeneo ( interi, decimali con virgola o punto e con uno o due cifre, decimali senza virgola e punto, errori di ortografia, ecc. mentre il formato del BMI è uniforme ad esempio ), scrivere una subquery light diventa ... arduo, almeno per me ...

Non è arduo solo per te. E' semplicemente impossibile fare tutte quelle operazioni che vuoi fare in un'unica colonna. punto

L'unico modo per venirne fuori potrebbe essere - forse - usare una colonna di appoggio . Cioè Nella colonna valore accertamento estrai il valore dell' ultimo accertamento (come è è, cioè senza badare al formato); nella colonna d'appoggio, invece, imposti le condizioni per dargli il formato che vuoi. Tieni presente che questa doppia colonna sarebbe solo per gli accertamenti con valore decimale (creatinina ed Hb glicata). Tutti gli altri (colesterolo,trigliceridi, BMI-che essendo un campo calcolato non dà problemi, perchè il suo formato è uniforme, come tu giustamente hai notato- ecc) non necessiterebbero di colonne d'appoggio .Certo poi i colleghi dovranno cancellare , a mano, le colonne superflue. Sarà questo un grandissimo problema ?

Se non avessi capito il tuo discorso sul formato dell date , scusami; ma non è semplice ragionare sul pensiero degli altri senza aver capito bene la logica che hai usato e basandomi solo sulle mie interpretazioni

Ciao

leonardo
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Admin il Sab 22 Set 2012 - 21:06

Variazione sul tema per l'estrazione del BMI nei pazienti diabetici:

SELECT p.cognome+' '+ p.nome Nome, p.datanasc Nascita, CAST( years(p.datanasc, data) as char (3)) eta,

(SELECT a.data_open FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
and a.ac_val > '' AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > ''AND x.data_open>a.data_open OR x.data_open=a.data_open AND x.ora>a.ora)) data,


(IF
(SELECT a.ac_val FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609' AND a.data_open=data ) IS NULL THEN 'Non registrato' ELSE
(SELECT a.ac_val FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609' AND a.data_open=data) ENDIF) BMI


FROM V_PAZIENTI p
WHERE EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb.nome_pbl like '%diabete%' )


Order By 1,2

Oppure

SELECT p.cognome+' '+ p.nome Nome, p.datanasc Nascita, CAST( years(p.datanasc, data) as char (3)) eta,

(SELECT a.data_open FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609'
and a.ac_val > '' AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND STRING (DATEFORMAT(x.data_open, 'YYYYMMDD'), x.ora) >STRING (DATEFORMAT(a.data_open, 'YYYYMMDD'), a.ora)) ) data,


(IF
(SELECT a.ac_val FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609' AND a.data_open=data ) IS NULL THEN 'Non registrato' ELSE
(SELECT a.ac_val FROM cart_accert a WHERE a.codice = p.codice AND ac_code = '2609' AND a.data_open=data) ENDIF) BMI


FROM V_PAZIENTI p
WHERE EXISTS (SELECT pb.codice FROM cart_pazpbl pb WHERE pb.codice = p.codice AND pb.nome_pbl like '%diabete%' )


Order By 1,2

Questo può andar bene per il BMI in quanto nello stesso giorno millewin non accetta 2 valutazioni, invece quando si tratta di accertamenti che possono essere prescritti più di uno nello stesso giorno per essere eseguiti in giorni diversi (ad es, 4 glicemie), conviene inserire la data di esecuzione quando si registra il risultato, oppure usare una estrazione del genere:

SELECT p.cognome+' '+ p.nome Nome, p.datanasc Nascita, CAST( years(p.datanasc, data) as char (3)) eta,

( SELECT max(a.data_open) FROM cart_accert a WHERE a.codice = p.codice AND ac_des like 'glicemia' AND ac_val is not null
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string(CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)) ) ) as Data,


( SELECT max(a.ac_val) FROM cart_accert a WHERE a.codice = p.codice AND ac_des like 'glicemia' AND ac_val is not null
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string(CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)) ) ) as valore,


( SELECT max(a.data_open) FROM cart_accert a WHERE a.codice = p.codice AND ac_des like 'glicemia' AND ac_val is null
AND not exists (SELECT x.codice from cart_accert x WHERE x.codice = p.codice AND x.ac_code = a.ac_code and x.ac_val > '' AND string(CAST(x.data_open AS TEXT), CAST(x.time_last AS TEXT)) > string(CAST(a.data_open AS TEXT), CAST(a.time_last AS TEXT)) ) ) as Senza_risposta


FROM V_PAZIENTI p
Where EXISTS (SELECT x.codice FROM cart_accert x WHERE x.codice = p.codice AND x.ac_des like '%glicemia%' )


Order by 1,2

In questo caso si estrae l'ultimo valore, ma la data risulta quella della prescrizione (se non si inserisce la data di esecuzione), comunque si tratta di sottigliezze.

_________________
L'Amministratore
Giuseppe Blasio
Admin
Admin
Admin
Admin

Messaggi : 525
Punti : 3605
Voti per importanza dei messaggi : 85
Data d'iscrizione : 20.02.11
Località : CASERTA

Visualizza il profilo http://utentimillewin.forumattivo.it

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Cervino il Mar 25 Set 2012 - 2:08

Chiedo scusa ma forse sono io a non avere chiarito adeguatamente il problema, comunque marginale ;
usando una delle formule da Voi suggerite ( Convert , DateFormat , ... ) posso dare al campo data il formato che desidero; tuttavia lo converto in stringa e quindi l' SQL di MW non lo riconosce piu' ovviamente coma data, quando cerco di creare una interdipendenza fra
alcuni campi e/o clausole all' interno di una query.
Quindi al fine di avere una chiara formattazione dei campi nel set estratto, necessito di un campo data con indicazione dell' anno a 4 cifre
( formato tipo yyyy-mm-dd o viceversa e simili ) e che venga riconosciuto come data dall' SQL di MW per creare relazioni di interdipendenza
che semplificano l' impostazione di una query ( al fine ad esempio di poter utilizzare una subquery del tipo :

(Select a.ac_val From cart_accert a Where a.codice = p.codice And ac_des Like '%BMI%' And a.data_open Like _BMI_d_ )
_Bmi_,
.

Usando una funzione del tipo : Cast( a.data_open As date ) oppure Cast( Convert( VarChar(15),'2012-12-31',112) As Date) e simili, ottengo sempre solo il formato : dd/mm/yy ma non l' anno a 4 cifre, con conseguenti problemi di conversione del formato data, nel foglio di calcolo ( specie per la data di nascita, se non si conosce il paziente ) e/o di allineamento ( oltretutto con formati data del tipo yyyy-mm-dd e simili non è ovviamente piu' necessaria la conversione ).

Quindi, semplicemente, esiste una formula per dare all' anno del campo data il formato 4 cifre ( tipo yyyy-mm-dd e simili ), riconosciuto come Data ( Non stringa o Testo ) dall' SQL di MW ?

Grazie per la vostra disponibilità , Vi saluto , Sergio


Cervino
Membro Junior
Membro Junior

Messaggi : 234
Punti : 3196
Voti per importanza dei messaggi : 19
Data d'iscrizione : 03.03.11
Età : 64
Località : Orzivecchi (BS)

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Cervino il Mar 25 Set 2012 - 2:23

Comunque Leonardo,
non mi sono perso d' animo ed alla fine, grazie anche ai Vostri suggerimenti, dovrei essere riuscito nell' ottenere la formattazione richiesta, non senza motivo, nel report da inviare all' ASL ( in una query di 72 colonne, il limite in W7 a 64 bit ).
Probabilmente il dbeng7.exe*32 ... soffrirà forse un po' ... con qualche minima imprecisione su complessi Mille.db MultiUtente ( ma riuscirà l' estrazione ? ) .
il set estratto ha un aspetto grafico intuitivo e semplifica di molto l' analisi statistica e purtroppo per Noi MMG, è piu' semplice individuare
per il Controllore eventuali discrepanze : ma non sarà forse meglio ritornare alla formattazione di default ?.

Ciao , Sergio

PS: Mi viene riferito che per alcuni Colleghi, manipolare un foglio di calcolo rappresenta un problema troppo arduo ... e quindi improponibile , come pure ogni modifica anche delle clausole piu' banali in una query, come introdurre il proprio Codice Medico Regionale o Nome Utente .


[quote="draleo83"][/font][/color]
Cervino ha scritto:comunque la situazione è complessa in quanto i valori decimali vanno convertiti in interi, moltiplicando *10 o *100 : quando il campo è disomogeneo ( interi, decimali con virgola o punto e con uno o due cifre, decimali senza virgola e punto, errori di ortografia, ecc. mentre il formato del BMI è uniforme ad esempio ), scrivere una subquery light diventa ... arduo, almeno per me ...

Non è arduo solo per te. E' semplicemente impossibile fare tutte quelle operazioni che vuoi fare in un'unica colonna. punto

L'unico modo per venirne fuori potrebbe essere - forse - usare una colonna di appoggio . Cioè Nella colonna valore accertamento estrai il valore dell' ultimo accertamento (come è è, cioè senza badare al formato); nella colonna d'appoggio, invece, imposti le condizioni per dargli il formato che vuoi. Tieni presente che questa doppia colonna sarebbe solo per gli accertamenti con valore decimale (creatinina ed Hb glicata). Tutti gli altri (colesterolo,trigliceridi, BMI-che essendo un campo calcolato non dà problemi, perchè il suo formato è uniforme, come tu giustamente hai notato- ecc) non necessiterebbero di colonne d'appoggio .Certo poi i colleghi dovranno cancellare , a mano, le colonne superflue. Sarà questo un grandissimo problema ? [/font][/color]

Ciao


Cervino
Membro Junior
Membro Junior

Messaggi : 234
Punti : 3196
Voti per importanza dei messaggi : 19
Data d'iscrizione : 03.03.11
Età : 64
Località : Orzivecchi (BS)

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Lucio Mignone il Mar 25 Set 2012 - 8:49

Sergio,
posso chiederti una volta definita la query su cui stai lavorando di postarla sul forum.
Mi potrebbe essere utile.
Lucio Mignone
Lucio Mignone
Membro Senior
Membro Senior

Messaggi : 626
Punti : 3741
Voti per importanza dei messaggi : 34
Data d'iscrizione : 20.02.11
Età : 55
Località : CAVRIGLIA (AR)

Visualizza il profilo http://comeva.altervista.org/

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  draleo83 il Mar 25 Set 2012 - 19:01

Cervino ha scritto:
Quindi, semplicemente, esiste una formula per dare all' anno del campo data il formato 4 cifre ( tipo yyyy-mm-dd e simili ), riconosciuto come Data ( Non stringa o Testo ) dall' SQL di MW ?

Grazie per la vostra disponibilità , Vi saluto , Sergio


Probabilmente esisterà una formula del genere, ma non l’ho trovata (occorre spenderci un po’ più di tempo per cercarla). Comunque si fa prima con un esempio molto semplice

Nella query sottostante vengono estratti i paz che hanno un’età infer 10 anni circa (365*10=3650), calcolata all’età della query:2012-12-31. In essa le date hanno a video il formato testo( come da te voluto) ; i conteggi invece sono fatti con datanasc e data_query in formato data. Mi sembra che funzioni

------------------------------------------------------

Select cognome, nome, Cast (datanasc As Char(16)),

cast('2012-12-31' as Char(16)) as data_query, DATEDIFF(YY,datanasc,data_query)eta

from V_pazienti where datanasc Between

cast(data_query as date)-3650 And cast(data_query as date)

order by 1,2

------------------------------------------------------------

Stranamente funziona anche semplificata così (ma non chiedermi perché, perché non lo so)

-----------------------------------------------------------------

Select cognome, nome, Cast (datanasc As Char(16)),

cast('2012-12-31' as Char(16)) as data_query, DATEDIFF(YY,datanasc,data_query)eta

from V_pazienti where datanasc Between

cast(data_query as date)-3650 And data_query

order by 1,2

------------------------
draleo83
draleo83
Membro Junior
Membro Junior

Messaggi : 217
Punti : 3225
Voti per importanza dei messaggi : 24
Data d'iscrizione : 21.02.11

Visualizza il profilo

Torna in alto Andare in basso

Re: BMI in diabetici

Messaggio  Contenuto sponsorizzato


Contenuto sponsorizzato


Torna in alto Andare in basso

Torna in alto


 
Permessi di questa sezione del forum:
Non puoi rispondere agli argomenti in questo forum