Mapatura campi SQL Express 2008 non corretta

martedì 10 maggio 2011 - 16.39

zactime Profilo | Newbie

Un saluto a tutti.

Crystal Report 2008 - SQL Express 2008.

Per creare un nuovo report opero come segue:
1 – Apro Crystal Report
2 – Clicco su Report vuoto
3 – Clicco sul + di Crea nuova connessione
4 – Clicco sul + di OLE DB (ADO)
5 – Clicco su Microsoft OLEDB Provider for SQL Server
6 – Clicco su Avanti
7 – Scego il nome server
8 – Indico il nome utente e la password
9 – Scego il nome del database dall’elenco
10 – Lascio Protezione integrata a False
11 – Clicco sul pulsante Fine senza modificare nulla
12 – Una volta ritornato alla form dove avevo creato la nuova connessione clicco sul + del nome del database
13 – Clicco sul + di dbo (elenco tabelle)
14 – Seleziono la o le tabelle coinvolte nel report
15 – Clicco sul pulsante OK
16 – Eventualmente, se sono coinvolte più tabelle relazionate fra loro, verifico con un doppio click sulla linea di collegamento la correttezza del collegamento stesso
17 – Inizio a creare il report

E qui mi accorgo del problema.
Infatti i campi che nel database sono di tipo Date (non DateTime), Crystal me li mappa come String di 10.
Perchè?????
Come faccio a far si che siano mappati come campi Date (solo data)?

Per aggiungere carne al fuoco... se, in fase di creazione della connessione, invece di scegliere "Microsoft OLEDB Provider for SQL Server" scelgo "SQL Server Native Client 10.0", Crystal me li mappa come Dati ese vado a formattare il campo lo tratta come una data.

Grazie anticipatamente a tutti quelli che mi aiuteranno.

Oscar

freeteo Profilo | Guru

Ciao zactime,
come ti sei accorto è un problema sul tipo di dati che torna il provider stesso, ad esempio non è detto che SqlNative e Oledb che si connette a SQL tornino gli stessi tipi di dati, ognuno ha i suoi, anche se spesso sono comuni o cmq il report li vede come gli stessi tipi.

Adesso non so bene quale sia la tua scelta sul provider e soprattutto come gli passi i dati poi a runtime, perchè ad esempio a me capita di passare delle Collection<T> oppure delle DataTable caricate a codice, quindi il designer del report mi serve per fargli sapere che campi ci saranno, ma non mi interessa che sia lo stesso db di produzione, spesso infatti uso dei db Access temporanei addirittura...

Ad ogni modo, tieni presente che puoi farti anche dei campi formula nel report, quindi anche se nel designer il campo data te lo vede come stringa, puoi farti un campo formula dove converti in data quel campo stringa e poi usi quest'ultima formula come oggetto del report...

Ciao.

Matteo Raumer
[MCAD .net, MVP Visual C#]
http://blogs.dotnethell.it/freeteo

zactime Profilo | Newbie

Ciao Matteo,
innanzitutto grazie per la risposta.

Come provvider avevo scelto inizialmente Microsoft OLEDB Provider for SQL Server optando successivamente per SQL Server Native Client 10.0.
Ho scelto quest'ultimo per un duplice motivo: perchè mi restituiva i formati che mi aspettavo e perchè consigliatomi dall'unica persona che mi ha risposto oltre a te, sul forum di Crystal.

Io disegno i report partendo dal database e da VB, a runtime, passo un DataSet.

Quando, inizialmente, usavo Microsoft OLEDB Provider for SQL Server, per aggirare il problema avevo usato le formule.
Però mi sembrava francamente assurdo.

In ogni caso sfruttando SQL Server Native Client 10.0 come provvider sembra che il problema sia risolto.

Grazie ancora.

Oscar

freeteo Profilo | Guru

>Ciao Matteo,
>innanzitutto grazie per la risposta.
di niente figurati, siamo qui per questo.



>Come provvider avevo scelto inizialmente Microsoft OLEDB Provider
>for SQL Server optando successivamente per SQL Server Native
>Client 10.0.
>Ho scelto quest'ultimo per un duplice motivo: perchè mi restituiva
>i formati che mi aspettavo e perchè consigliatomi dall'unica
>persona che mi ha risposto oltre a te, sul forum di Crystal.
ok



>Io disegno i report partendo dal database e da VB, a runtime,
>passo un DataSet.
ok, infatti quasi sempre mi è capitato di optare per questa strada, perchè la ritengo la migliore in termini di evoluzione/personalizzazioni/affidabilità etc...
Anche se a livello prestazioni potrebbe essere leggermente più lento, non è sicuramente paragonabile al vantaggio reale che hai, ad avere sotto controllo i dati del report che potrebbero provenire dalle sorgenti più disparate.



>Quando, inizialmente, usavo Microsoft OLEDB Provider for SQL
>Server, per aggirare il problema avevo usato le formule.
>Però mi sembrava francamente assurdo.
concordo, il mio era solo un suggerimento nel caso in cui ti trovassi a dover lasciare intatto l'accesso ai dati



>In ogni caso sfruttando SQL Server Native Client 10.0 come provvider
>sembra che il problema sia risolto.
infatti, il driver arriva nativo per windows proprio da Ms quindi era abbastanza d'obbligo che Crystal lo supportasse a pieno

Ciao.

Matteo Raumer
[MCAD .net, MVP Visual C#]
http://blogs.dotnethell.it/freeteo

zactime Profilo | Newbie

Bene, mi fa piacere capire che sono sulla strada giusta.

Grazie ancora.

Oscar
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2017
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5