Gode fremgangsmåter for rapporter

Følgende gode fremgangsmåter kan hjelpe deg med å lage rapporter som er enklere å skrive, overholde etablerte standarder og kjøre dem mer effektivt.

Generelle gode fremgangsmåter

I denne delen finner du gode fremgangsmåter for å opprette egendefinerte Fetch-baserte rapporter.

Bruke en eksisterende rapport for å opprette egendefinerte rapporter

Se om det finnes en eksisterende rapport i appen som ligner på utformingen du ser etter. Last ned rapportdefinisjonen for rapporten, og endre deretter RDL-filen i stedet for å opprette en ny fra bunnen av. Ved å gjøre dette vil du spare utviklingstid og redusere rapportskrivefeil.

Bruke Customer Engagement (on-premises)-formater for valuta, tall, dato og klokkeslett og kalender

FilteredUserSettings-visningen inneholder informasjon om valutaformat, dato og klokkeslett-format, tallformat, negativt tall, startdag i uken, kalendere og andre formater. Customer Engagement (on-premises) inneholder databasefunksjonen fn_GetFormatStrings som henter dato-, klokkeslett-, tall-, valuta- og kalenderformat fra FilteredUserSettings-visningen.

Bruk disse ressurser til å formatere riktige dataverdiene i rapportene.

Angi sidestørrelsen

Reporting Services inneholder ikke eksplisitt papirretning, for eksempel stående og liggende modus eller forhåndsdefinerte sidestørrelser. Standardrapporter er utformet for 8,25 x 11 (stående) eller 11 x 8,25 (liggende) sidestørrelser som fungerer for både US letter- og A4-papir.

Sikkerhetskopiere rapportene

Sikkerhetskopier rapportene og lagre dem på en annen datamaskin enn rapporteringsserveren.

Angi avkorting hvis nødvendig

Tekstbryting er standard virkemåte for et tekstboksrapportelement i Reporting Services. Dette betyr, med mindre noe annet er angitt, at all tekst brytes ved den definerte bredden på et tekstområde og så økes loddrett. Hvis det er angitt avkorting, avkorter en tekstboks teksten til bredden på tekstboksen innenfor den angitte utfyllingen (standard er 2 pt venstre og høyre). All maksimumslengdeavkorting utover dette krever egendefinert koding.

Standardrapporter er konfigurert med verktøytips som viser statisk tekst eller verdier fra datafelt når brukeren holder musepekeren over rapportelementet. Hvis du bruker avkorting, bør du vurdere å sette ToolTip-egenskapen til feltverdien slik at hele teksten vises når brukeren holder pekeren over den avkortede teksten.

Gode fremgangsmåter når du oppretter rapporter som inkluderer dato og klokkeslett-felt

Når du oppretter rapporter som bruker dato og klokkeslett-felt, må du være klar over følgende:

• Hvis du skal være konsekvent med dato og klokkeslett-verdiene i Customer Engagement (on-premises), når du oppretter rapporter som bruker et Coordinated Universal Time (UTC)-basert felt (Tidssoneuavhengig eller Bare dato), må du ikke konvertere verdien til en regional tidssonebasert (Brukerlokal) verdi.

• Hvis du endrer dato og klokkeslett-virkemåten for et felt i en enhet, må du kanskje generere rapporter som bruker denne datoen og dette klokkeslettet i rapporten, på nytt slik at feltet vises på riktig måte.

  • Generer rapporter som er opprettet med rapportveiviseren, på nytt. Rediger rapporten ved hjelp av rapportveiviseren med samme parametere for å generere rapporten på nytt.

  • Generer rapporter basert på en administrert løsning. Ved administrerte løsninger kan du i stedet for å redigere rapporten importere løsningen på nytt, når du skal generere rapporten på nytt.

  • Generer egendefinerte rapporter som er opprettet med Visual Studio, på nytt. Oppdater dato og klokkeslett-feltet i Visual Studioetter behov, og publiser rapporten på nytt.

  Hvis du vil ha mer informasjon om dato og klokkeslett-felt, kan du se Virkemåten til Dato og klokkeslett-datatypen.

Se også

Veiledning for rapportering og analyse
Forbedre ytelsen til rapporter