Newsgroup: it.lavoro.informatica
Titolo: Estrazione dati da db MS Sql Server 2005

Chiedo scusa per l'IT...
ho un database MS SQLServer 2005 che è utilizzato
da un software CRM che si chiama
Movex Sales & Marketing System (SMS)
ora questo crm fa veramente c@..are ma ormai è stato preso
e pazienza.... il problema è che hanno bisogno di report sulle
visite, numero, media, tipo di attività, ecc. per venditore.
Riesco ad ottenere un mallopone in pdf con la descrizione
del database e mi dico: "sono a cavallo" e quindi vai con:
select * from activity ecc. ecc.
dunque, le date sono così: 39413.625555555554 e come mi
è stato suggerito su it.comp.software.database ho fatto questo:
SELECT CAST(STARTDATE AS datetime) AS Data1
che mi restituisce una data umana: 2007-11-29 15:00:47.997
mah!!!
se interrogo la stessa visita dall'applicativo (un client VB suppongo)
le date sono tutte due giorni indietro, in questo caso sarebbe il 27/11
come ottengo la data corretta? ... in java

il 08/10/2008 15.36, Scrive Cosimo Piceno 31106792:

Il MS sql server, differentemente da tutti i db seri, non implementa 
DATE TIME e TIMESTAMP, gia' presenti nell'iso'92, ma quella ciofeca del 
DATETIME che altro non e' che il formato della data dell'excel, ovvero 
la mantissa rappresenta il numero di giorni trascorsi dal 1/1/1900 e la 
caratteristica che rappresenta la porzione di tempo trascorsa dalla 
mezzanotte (quindi mezzogorno e' 0,5), valori negativi si riferiscono a 
date precedenti alla data base. Da cui se ne deduce che:
GregorianCalendar base = new GregorianCalendar(1900, 1, 1)
rappresenta la data base
int giorni = (int)39413.625555555554
e' la data
int millisecondi= (int)((double)(39413.625555555554 - giorni))*86400000
e' l'ora (86400 secondi per giorno solare medio)
per cui la data sara'
base.add(Calendar.DAY_OF_MONTH, giorni )
crea la nuova data
base.add(Calendar.MILLISECOND, millisecondi)
Date data = base.getTime();
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

 DATETIME che altro non e' che il formato della data dell'excel
bene!
allora mi trasferisco in ambiente MS Office così tutto andrà a posto!!!
scarico il driver ODBC e provo a estrarre i dati in Excel tramite
Microsoft Query...
- e cosa c'entra con Java? -
voglio vedere se attraverso il driver ODBC i dati siano convertiti
ed eventualmente usare il bridge invece del jdbc
Bello,
la selezione sulle date non converte i valori per cui se voglio
selezionare un periodo devo impostare per es.
startDate>=39413.625555555554 AND startDate<=39413.625555555554
davvero comodo ...
no dai, basta così,
ho deciso in questo preciso istante che rifiuto il lavoro. 

il 09/10/2008 10.22, Scrive Cosimo Piceno 31106792:

Non conosci le le meraviglie del ms-sql server?
Comunque se il campo db e' definito come datetime, puoi selezionare 
anche con la data in forma "human", ovviamente human secondo m$, ovvero 
la data la devi formattare secondo la locale del server! Ad esempio, sul 
mio, che e' italiano, devo mettere dd/mm/aa. Ma il problema del range 
pero' rimane, nel senso che, non essendo previsto il tipo sql DATE non 
posso neanche fare il cast e devo per forza mettere un range con 
avvertenza di non indicare i millisecondi altrimenti arrotonda! Mi spiego:
where startDate>='01/01/2008 00:00:00.000' AND startDate<='01/01/2008 
23:59:59.999'
ti estrae anche le date '02/01/2008 00:00:00.000' per effetto 
dell'arrotondamento automatico dei 999 all'ora successiva. Poiche' e' 
documentato che la definizione e' di 0.003 millisecondi io avrei detto 
che esendo .999 divisibile per .003 potesse andar bene, ma invece no. 
Inoltre arrotonda anche nell'insert (a caso per quanto possa aver 
rilevato), per cui occorre immettere i campi orario definiti al 
centesimo, altrimenti non riesci a selezionarli, di conseguenza la where 
dovra' essere
where startDate>='01/01/2008 00:00:00.00' AND startDate<='01/01/2008 
23:59:59.99'



O anche (che stai prima e te ne puoi fregare delle impostazioni sulla 
lingua) visto che in realtà del tempo non ci frega nulla:
where startDate >= '20080101' and startDate < '20080102'

 lingua) visto che in realtà del tempo non ci frega nulla:
Certo, era cer mettere sull'avviso del potenziale arrotondamento sul 
terzo decimale. (che mi sembra un'idiozia)



Ma lo statement finale dovrebbe essere appunto una cosa del tipo:
.... where StartDate >=@Da and startDate <= @A
Dove @Da e @A sono parametri di tipo data e sono passati a metodi di 
libreria (
ADO.NET
 per esempio se lo statement parte dal client, oppure a 
sp_executesql se č autogenerato lato server (che č poi quello che generano 
alla fine le librerie lato client)), quindi non c'č proprio nessuna 
formattazione da dover dare a mano alle stringhe.

ERROR : com.microsoft.sqlserver.jdbc.SQLServerException:
No se encontró el procedimiento almacenado 'qry'.
tornando al tema del gergo informatico in altri paesi:
"procedimiento almacenado" 

 formattazione da dover dare a mano alle stringhe.
Capisco. Capisco anche che questo tipo di approccio potra' anche 
risultare normale per uno che utilizza normalmente gli ambienti windows.
Ti garantisco però, che non lo e' assolutamente per chi lavora in 
ambienti eterogenei, dove un linguaggio (vedi p.e. SQL) e' un lnguaggio 
(lo stesso in qualsiasi ambiente) e come tale va trattato, ovvero una 
convenzione universalmente conosciuta ed accettata per quello che gli 
organismi di standardizzazione propongono. In base a tale convenzione 
non ho bisogno di sapere come e perche' 
ADO.NET
 interagisce con le mie 
richieste SQL.
Mi rendo anche conto che, con tutte le lacune di ms SQLServer rispetto 
allo standard, non dev'essere facile ottenere buoni risultati senza 
interagire con interfacce esterne.


 formattazione da dover dare a mano alle stringhe.
purtroppo non uso 
ADO.NET
 , ma Java
se non faccio il cast
SELECT ... StartDate,
e se estraggo la stringa mi da la solita ciofeca
resultset.getString("StartDate")   risultato -> 39513.37527777778
mentre se estraggo la data....
resultset.getDate("StartDate")
com.microsoft.sqlserver.jdbc.SQLServerException: La conversione da float a 
DATE non è supportata.
per tirare fuori qualcosa devo fare come mi era stato suggerito in origine:
SELECT .... CAST(Activity.StartDate AS datetime) AS data1,
resultset.getDate("data1")   risultato -> 2008-03-08

Cosimo Piceno ha scritto:

Credo voglia dire "file/programma non trovato"...

 
E sai che sia giusto?
A me risulta
39513.37527777778 = Tue Apr 08 09:00:23 CEST 2008
che se fosse una data formato excel (aka ms sql server) come risultato 
va bene, perche'
39513 - 25 giorni bisestili nei 108 anni trascorsi = (39488/365) = 
108,1863013698630136986301369863
365 * 0,1863013698630136986301369863=~68
che, come risultato di sommaria verifica, assomiglia di piu' all' 8 
Aprile piuttosto che all'8 Marzo
L'ho fatto con questo:
import java.util.*;
public class Dataex {
  public static void main(String[] args) {
   double dataexcel = Double.parseDouble(args[0]);
   GregorianCalendar base = new GregorianCalendar(1900, 1, 1);
   int giorni = (int)dataexcel;
   int millisec = (int)(((double)(dataexcel-(1.0 * giorni)))*86400000);
   base.add(Calendar.DAY_OF_MONTH, giorni );
   base.add(Calendar.MILLISECOND, millisec);
   Date data = base.getTime();
   System.out.println(args[0] + " = " +data);


il 09/10/2008 16.01, Scrive Quasimodo 31106792:

No, un "procedimiento almacenado" e' una stored procedure.
Quindi sqlserver pensava di dover cercare una stored procedure di nome 
'qry' ma non l'ha trovata.



Non sono stato spiegato :-)
Lasciando perdere il problema di Cosimo che deve smazzarsi per recuperare 
date su un DB dove qualcuno chissa' per quali motivi  ha usato i float 
invece che i datetime per definirle, io ho solo detto che non è vero che MS 
SQL Server è "strano" circa il trattamento delle date, basta sempre usare la 
notazione ISO e non c'è nessun problema nella conversione implicita da 
stringa a datetime. Se a uno piace di più usare la notazione stile inglese, 
allora basta che assegni l'inglese come lingua associata alla login che usa 
quando si connette a SQL Server, oppure ancora, pinciona con il set 
dateformat ogni volta che vuole far convertire stringhe in datetime.
E poi il mio discorso sulla concatenazione di stringhe non riguardava le 
query che uno si vuole costuire al volo da dentro una query-window dove per 
forza di cose le date sono da indicare usando delle stringhe, ma era 
riferito al fatto di creare concatenazioni lato applicativo andando in 
contro al problema dello sql-injection che mica è solo di MS SQL Server, ma 
è un concetto applicabile a tutti gli engine.

 è un concetto applicabile a tutti gli engine.
Ok, ora ci siamo! :-)
Io in realta' mi riferivo tiu' che altro alla sintassi dell'SQL.
Volevo tranquillizzarti: neach'io concateno direttamente le stringhe nel 
programma, in genere uso degli strumenti che evitano l'sql-injection ed 
adattano i tipi dati del linguaggio applicativo ai tipi sql.



no! :(
se consulto tramite l'applicazione
39513.37527777778 --->  06/03/2008  09:00:24
39513.41694444444 --->  06/03/2008  10:00:24
due giorni indietro 

il 09/10/2008 17.24, Scrive Cosimo Piceno 31106792:

E allora mi sa che quel numero non sia un formato excel, oppure chi lo 
scrive considera erroneamente bisestili il 1900 ed il 2000, che 
giustificherebbe i due giorni.
Oppure usano un time-zone un po' particolare!
:-))
