25
Sage OfficeLine Abfragen dauern zu lange (MS SQL Server 2008 64bit CPU IO Speicher nicht ausgelastet... wie kriegt man da mehr Performance rein, so dass die Hardware genutzt wird?
Die Performance im Alltagsbetrieb bringt lange Wartezeiten bei komplexen Auswertungen...
Hallo,
wir haben folgendes Setup laufen:
ESX Server 4.1 auf Dell R710 mit 2x Xeon 5620 2,4 Ghz, 48 GB RAM, RAID10 Storage
Konfiguration der VM's:
Terminal Server: Win2008 R2, 4 vCPU, 12 GB RAM (laut Windows werden immer so um die 7 GB genutzt, Rest frei)
Datenbank Server: Win2008 R2, 4 vCPU, 16 GB RAM ( laut Windows werden leider nur ca. 8 GB genutzt)
Daten zum MS SQL 2008 Server:
-Nutzt meistens so um die 5-6 GB an Arbeitsspeicher
-Activity Monitor sagt bei einer komplexen Abfrage die einfach zu lange dauert: % Processor time 0-1% Waiting Tasks sehe ich immer 0 ... Database I/O zwischen 0 und 0.1 MB/sec ... Batch Requests meistens so um die 5-8
Irgendwie hört sich das alles recht wenig an? Die CPU Last des Datenbank Servers liegt selbst bei Abfragen nicht höher als 3-4%. Der freie Arbeitsspeicher, den die Maschine hat, bleibt ungenutzt.
Dennoch dauern manche Berichte (viele Abfragen) bis zu 5 Minuten und das obwohl die Datenbank Gesamt nur eine aktuelle Größe von ca. 1,2 GB hat.
Wo kann hier das Problem liegen? Oder liegt das Problem gar nicht beim Datenbankserver? Die Sage OfficeLine nutzt ja Microsoft Access als Frontend auf dem Terminalserver. Hier ist die Auslastung so bei 10-20% wenn ein
komplexer Bericht gerechnet wird. Ich würde gerne folgendes erreichen, dass der Terminal Server die Abfragen schneller vom SQL Server geliefert bekommt, denn Fakt ist doch Hardwaretechnisch können beide Systeme deutlich mehr.
Auch die Festplatten I/Os im vCenter sind nicht übermässig beansprucht.
Freue mich über ein paar Vorschläge.
Danke und Gruß, Benny
Hallo,
wir haben folgendes Setup laufen:
ESX Server 4.1 auf Dell R710 mit 2x Xeon 5620 2,4 Ghz, 48 GB RAM, RAID10 Storage
Konfiguration der VM's:
Terminal Server: Win2008 R2, 4 vCPU, 12 GB RAM (laut Windows werden immer so um die 7 GB genutzt, Rest frei)
Datenbank Server: Win2008 R2, 4 vCPU, 16 GB RAM ( laut Windows werden leider nur ca. 8 GB genutzt)
Daten zum MS SQL 2008 Server:
-Nutzt meistens so um die 5-6 GB an Arbeitsspeicher
-Activity Monitor sagt bei einer komplexen Abfrage die einfach zu lange dauert: % Processor time 0-1% Waiting Tasks sehe ich immer 0 ... Database I/O zwischen 0 und 0.1 MB/sec ... Batch Requests meistens so um die 5-8
Irgendwie hört sich das alles recht wenig an? Die CPU Last des Datenbank Servers liegt selbst bei Abfragen nicht höher als 3-4%. Der freie Arbeitsspeicher, den die Maschine hat, bleibt ungenutzt.
Dennoch dauern manche Berichte (viele Abfragen) bis zu 5 Minuten und das obwohl die Datenbank Gesamt nur eine aktuelle Größe von ca. 1,2 GB hat.
Wo kann hier das Problem liegen? Oder liegt das Problem gar nicht beim Datenbankserver? Die Sage OfficeLine nutzt ja Microsoft Access als Frontend auf dem Terminalserver. Hier ist die Auslastung so bei 10-20% wenn ein
komplexer Bericht gerechnet wird. Ich würde gerne folgendes erreichen, dass der Terminal Server die Abfragen schneller vom SQL Server geliefert bekommt, denn Fakt ist doch Hardwaretechnisch können beide Systeme deutlich mehr.
Auch die Festplatten I/Os im vCenter sind nicht übermässig beansprucht.
Freue mich über ein paar Vorschläge.
Danke und Gruß, Benny
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 168545
Url: https://administrator.de/forum/sage-officeline-abfragen-dauern-zu-lange-ms-sql-server-2008-64bit-cpu-io-speicher-nicht-ausgelastet-wie-168545.html
Ausgedruckt am: 19.04.2025 um 10:04 Uhr
25 Kommentare
Neuester Kommentar
Das größte Problem wird bei dir wohl das Storage sein, mit RAID10 bekommt man bei so kleinen Setups (ich geh bei dir mal von 4 oder 6 Festplatten aus) nicht richtig Druck dahinter. Wenn es um IOPS geht, soviele Spindeln wie möglich. Ich kenn relativ neue Storagesysteme, die sich im Einsatz befinden, aus etlichen hundert Festplatten bestehen und trotzdem weit weniger Speicherplatz bieten als ein 4-Bay NAS vom Händler um die Ecke. Alles nur weil wegen die IOPS. Aber das ist unwichtig, dein Problem liegt woanders.
Mehr RAM-Verbrauch beim Datenbankserver wird wohl nicht hinhauen. Das komplette Betriebssystem samt Datenbankserver und Datenbank scheint ja schon im RAM zu liegen, also kannst du da nichts weiter machen.
Dein Problem wird wohl die Software ansich sein. Ich geh mal davon aus, dass die Software nur einen Thread gleichzeitig laufen lässt, weil es das nicht besser kann oder nicht richtig konfiguriert ist. Sprich es wird immer nur ein einziger Kern benutzt für die Berichte und somit kann nur eine Aktion gleichzeitig ausgeführt werden. Ich bezweifel, dass MS Access Multithreaded arbeiten kann.
Sprich effektiv kannst du nichts machen, weils nicht in deinem Zugriffsbereich liegt.
Mehr RAM-Verbrauch beim Datenbankserver wird wohl nicht hinhauen. Das komplette Betriebssystem samt Datenbankserver und Datenbank scheint ja schon im RAM zu liegen, also kannst du da nichts weiter machen.
Dein Problem wird wohl die Software ansich sein. Ich geh mal davon aus, dass die Software nur einen Thread gleichzeitig laufen lässt, weil es das nicht besser kann oder nicht richtig konfiguriert ist. Sprich es wird immer nur ein einziger Kern benutzt für die Berichte und somit kann nur eine Aktion gleichzeitig ausgeführt werden. Ich bezweifel, dass MS Access Multithreaded arbeiten kann.
Sprich effektiv kannst du nichts machen, weils nicht in deinem Zugriffsbereich liegt.
Das RAID10 besteht aus 6x 10k SAS Platten. Wenn ich den vCenter Auswertungen Glauben schenke, ist das nicht das Problem...
Was ich einfach nicht verstehe, es ist genug Hardware da... es wird einfach nicht genutzt. Der SQL Server scheint sich zu langweilen bei der Geschwindigkeit, wie Access die Daten abfragt. Mir ist nur aufgefallen, dass MSACCESS.EXE eine CPU belastet mit ca. 25-50% und man zugucken kann wie die Speichernutzung der MSACCESS.EXE auf dem Terminal Server pro Sekunde ca. 1-2 MB ansteigt... bei komplexen Berichten gehts dann auch mal bis 600 MB....
Was kann man da machen, damit das irgendwie performanter wird?
Was ich einfach nicht verstehe, es ist genug Hardware da... es wird einfach nicht genutzt. Der SQL Server scheint sich zu langweilen bei der Geschwindigkeit, wie Access die Daten abfragt. Mir ist nur aufgefallen, dass MSACCESS.EXE eine CPU belastet mit ca. 25-50% und man zugucken kann wie die Speichernutzung der MSACCESS.EXE auf dem Terminal Server pro Sekunde ca. 1-2 MB ansteigt... bei komplexen Berichten gehts dann auch mal bis 600 MB....
Was kann man da machen, damit das irgendwie performanter wird?
Was auch etwas blöd ist... wenn eine komplexe Berichtsabfrage läuft und die MSACCESS.EXE Datei entsprechend "anschwillt" und man dann mit der Maus ungeduldig klickt (macht ein User gerne mal, da er denkt passiert nix mehr), kommt typisch Windows "Anwendung reagiert nicht mehr"... wenn man dann wartet erholt sich alles wieder sobald der fertige Bericht da ist.
Wie gesagt ist das mit dem Storage ein nicht signifikanter Gesamtfehler, also bei dir stoert er vorerst nicht. Dein Problem ist Access und das koennte nur Sage aendern. Du kannst da nicht gegen tun.
Na, dann hoffen wir mal Sage geht irgendwann von dem Access Front End weg... hat eben alles Vor- und Nachteile.
Das Storage Problem irgendwann ist klar...zu wenig Platten bei steigenden Plattenzugriffen ... dient als Übergang, in 1-2 Jahren kommt ein SAN in die Umgebung
Das Storage Problem irgendwann ist klar...zu wenig Platten bei steigenden Plattenzugriffen ... dient als Übergang, in 1-2 Jahren kommt ein SAN in die Umgebung
Hallo,
welche OL-Version ist im Einsatz?
Was für ein Bericht wird mit der Abfrage erstellt
Laufen regelmäßig Wartungspläne auf dem SQL-Server
Bestünde die Möglichkeit, den OL-Client (WaWi/ReWe) lokal auf einem Client zu installieren und dort die Performance zu prüfen.
Eine Trace-Log über den Profiler des SQL-Servers während der ABfrage wäre recht hilfreich.
welche OL-Version ist im Einsatz?
Was für ein Bericht wird mit der Abfrage erstellt
Laufen regelmäßig Wartungspläne auf dem SQL-Server
Bestünde die Möglichkeit, den OL-Client (WaWi/ReWe) lokal auf einem Client zu installieren und dort die Performance zu prüfen.
Eine Trace-Log über den Profiler des SQL-Servers während der ABfrage wäre recht hilfreich.
Hallo,
es ist die Office Line 2011 Evolution. Die Berichte sind über den Aufgaben Center gebaut und beziehen sich nur auf die Sage eigene OL Datenbank.
Was meinst Du genau mit Wartungspläne? Es wurde so konfiguriert, dass alle 2 Stunden ein Log File geschrieben wird. Das Backup wird immer abends gemacht ab 20 Uhr und hält die letzten 5 Tage zurück.
Ich habe parallel eine Testumgebung, auf der Maschine laufen direkt der SQL Server, sowie die Office Line. Leider ist es dort genau das gleiche Bild der Performance. Also nicht langsamer/schneller als Terminal/DB Server getrennt.
es ist die Office Line 2011 Evolution. Die Berichte sind über den Aufgaben Center gebaut und beziehen sich nur auf die Sage eigene OL Datenbank.
Was meinst Du genau mit Wartungspläne? Es wurde so konfiguriert, dass alle 2 Stunden ein Log File geschrieben wird. Das Backup wird immer abends gemacht ab 20 Uhr und hält die letzten 5 Tage zurück.
Ich habe parallel eine Testumgebung, auf der Maschine laufen direkt der SQL Server, sowie die Office Line. Leider ist es dort genau das gleiche Bild der Performance. Also nicht langsamer/schneller als Terminal/DB Server getrennt.
Hallo,
mit Wartungplan amit meine ich nicht nur das Sichern der Datenbank, sondern primär die Indexneuserstellung, Indexe organisieren, Statistiken organiseierne, Verlaufscleanup - also die Datenbankdatei auf "Vordermann" bringen. Was für einen Sicherungstypen nimmst Du denn, wie groß ist die ldf-Datei?
Die nächste Frage wäre, was für eine Antivierenlösung zum Einsatz kommt, ob diese eventuell stört. Dazu solltest Du folgende Datei-Endungen vom Scanvorgang ausschließen:
*.mde, *.mda, *.ldf, *.ade, *.adp, - ich hoffe, ich hab jetzt alle ^^
Ich denke um überhaupt erstmal irgendwo ansetzen zu können, solltest Du mit dem SQL-Server Profiler die Abfrage mitloggen und auswerten (oder veröffentlichen), denn die Dauer der einzelnen Anfragen werden dort angegeben.
mit Wartungplan amit meine ich nicht nur das Sichern der Datenbank, sondern primär die Indexneuserstellung, Indexe organisieren, Statistiken organiseierne, Verlaufscleanup - also die Datenbankdatei auf "Vordermann" bringen. Was für einen Sicherungstypen nimmst Du denn, wie groß ist die ldf-Datei?
Die nächste Frage wäre, was für eine Antivierenlösung zum Einsatz kommt, ob diese eventuell stört. Dazu solltest Du folgende Datei-Endungen vom Scanvorgang ausschließen:
*.mde, *.mda, *.ldf, *.ade, *.adp, - ich hoffe, ich hab jetzt alle ^^
Ich denke um überhaupt erstmal irgendwo ansetzen zu können, solltest Du mit dem SQL-Server Profiler die Abfrage mitloggen und auswerten (oder veröffentlichen), denn die Dauer der einzelnen Anfragen werden dort angegeben.
Zitat von @77705:
Eine Trace-Log über den Profiler des SQL-Servers während der ABfrage wäre recht hilfreich.
Eine Trace-Log über den Profiler des SQL-Servers während der ABfrage wäre recht hilfreich.
Das habe ich mir angesehen, das war wirklich hilfreich. Der SQL Server langweilt sich. Die Zeilen kann ich quasi an einer Hand abzählen. Es kommt für paar Sekunden Aktivität auf, dann ist wieder 1-2 Minuten nix los auf dem SQL Server. Parallel läuft sich aber MSACCESS.EXE heiss.... also bei einem Bericht mit 122.000 Zeilen und ca. 50 Spalten ging es in 1 Sek. Takt um ca. 1-2 MB höher und CPU fast bei 100% (1 CPU Maschine) Nach paar Minuten war der Bericht da....
Schade, dass Sage das so gelöst hat und man auf Access angewiesen ist. Gibt es bei der neuen Office Line 2012 Hoffnung, dass es mit Access 2010 besser läuft?
Zitat von @77705:
mit Wartungplan amit meine ich nicht nur das Sichern der Datenbank, sondern primär die Indexneuserstellung, Indexe
organisieren, Statistiken organiseierne, Verlaufscleanup - also die Datenbankdatei auf "Vordermann" bringen. Was
für einen Sicherungstypen nimmst Du denn, wie groß ist die ldf-Datei?
mit Wartungplan amit meine ich nicht nur das Sichern der Datenbank, sondern primär die Indexneuserstellung, Indexe
organisieren, Statistiken organiseierne, Verlaufscleanup - also die Datenbankdatei auf "Vordermann" bringen. Was
für einen Sicherungstypen nimmst Du denn, wie groß ist die ldf-Datei?
die Log .LDF ist 39 MB
die DATA .mdf ist 1,4 GB
Die nächste Frage wäre, was für eine Antivierenlösung zum Einsatz kommt, ob diese eventuell stört. Dazu
solltest Du folgende Datei-Endungen vom Scanvorgang ausschließen:
*.mde, *.mda, *.ldf, *.ade, *.adp, - ich hoffe, ich hab jetzt alle ^^
solltest Du folgende Datei-Endungen vom Scanvorgang ausschließen:
*.mde, *.mda, *.ldf, *.ade, *.adp, - ich hoffe, ich hab jetzt alle ^^
Auf dem SQL Datenbankserver ist kein Virenscanner aktiv. Dort wird nur 1x wöchentlich gescannt.
Es gibt doch für das Aufgabencenter einen eigenen Client. Wenn ihr den auch lizensiert habt könntest Du diese Abfrage direkt in dem AC-Client ausführen und prüfen ob es dort schneller läuft. Denn dann kommt die Access nich tzum tragen.
Eine weitere Alternative wäre, dass die DB-Abfrage aus dem Aufgabencenter (der Profiler sollte die Abfrage ja anzeigen) z.B. aus Excel heraus aufgerufen wird.
Eine weitere Alternative wäre, dass die DB-Abfrage aus dem Aufgabencenter (der Profiler sollte die Abfrage ja anzeigen) z.B. aus Excel heraus aufgerufen wird.
Der AC-Client ist genauso langsam... er heißt LS irgendwas 51.EXE ... gleiches Verhalten wie Excel...
Ist Excel denn schneller? Wie stelle ich das ein? Würde ich gerne mal testen...
Ist Excel denn schneller? Wie stelle ich das ein? Würde ich gerne mal testen...
Hi,
ich kenne das Produkt überhaupt nicht aber Berichte sind i.d.R. nur eine Anzeige also nichts, in das man Daten einpflegt?
Wenn das so der Fall ist, was spricht dann gegen die SQL Server Reporting Services, die sind dafür die bessere Wahl.
Gruß
ich kenne das Produkt überhaupt nicht aber Berichte sind i.d.R. nur eine Anzeige also nichts, in das man Daten einpflegt?
Wenn das so der Fall ist, was spricht dann gegen die SQL Server Reporting Services, die sind dafür die bessere Wahl.
Gruß
Die Abfragen ergeben sich jedoch aus dem Programm Sage Office Line und wurden dort definiert.... es soll benutzerfreundlich sein. Wie soll das gehen? Es muss doch aus Sage gestartet werden?
Du kennst doch die Abfragen aus dem Profiler, die Angaben der where Klausel werden parametriert und fertig ist das Ding.
Es gibt doch in dem Programm x definierte Reports oder kann sich jeder User vollkommen dynamisch zusammenklicken, was er möchte?
Wie gesagt ich kenne das Programm überhaupt nicht sorry.
Benutzerfreundlich ist es definitiv, du wählst aus Dropdown Boxen deine X Parameter und klickst Anzeigen.
Ich weiß nicht, ob du dich damit auskennst, wenn du Fragen hast, BI mit MSSQL mache ich fast täglich frag, was du wissen möchtest.
Es gibt doch in dem Programm x definierte Reports oder kann sich jeder User vollkommen dynamisch zusammenklicken, was er möchte?
Wie gesagt ich kenne das Programm überhaupt nicht sorry.
Benutzerfreundlich ist es definitiv, du wählst aus Dropdown Boxen deine X Parameter und klickst Anzeigen.
Ich weiß nicht, ob du dich damit auskennst, wenn du Fragen hast, BI mit MSSQL mache ich fast täglich frag, was du wissen möchtest.
Bei Sage gibt es den netten Aufgaben-Center. Hier kann man sich aus SQL Tabellen mit Hilfe eines Assistenten eigene Berichte zusammenstellen. Die Standard Sage Berichte sind Mist, da dort z.B. Benutzerdefinierte Felder nicht bei sind. Wir nutzen Sage mit Application Server, steuern also über ein externes operatives System Aufträge rein, daher haben wir einige Benutzerdefinierten Parameter. All diese sind in keinem Standard Report drin. Daher haben wir uns alle Reports teils selbst, teils mit unserem Sage Partner zusammengebaut. Das ist echt genial, wäre da nicht die Geschwindigkeit 
Okay, ich schaue mir morgen das Programm mal an, ich denke nämlich immernoch, dass man jeden eurer reports 1:1 abbilden kann.
Das ist ja imer noch akut? *lach*
Also: Prinzipiell ist so, dass eine Datenbank vorliegt und dementsprechend jeder Bericht tatsächlich über den SQL-Server selbst laufen könnte. Willst Du allerdings selbst Abfragen schreiben liegt das Problem darin dass nicht alle Informationen in der Datenbankstruktur wiedergefunden werdne können. Falsch, könne sie natürlich, Du musst nur wissen wo was liegt. Ich weiß jetzt gerade die Tabellennamen und Inhalte nicht auswendig. Ich weiß aber dass Du nicht alle Informationen zu einem Thema (Adressen/Artikel...) in einer Tabelle hast.
Zum Geschwindigkeitsproblem. Wenn Du den TraceLog gestartet hast siehst Du ja welche SQL-Befehle durch den Client abgefeuert werden. Wie ist die Performance wenn Du diese Statements direkt im SQL-Server ausführst? Lahmt das dann auch?
Eventuell wäre es hilfreich wenn Du Sichten im SQL-Server anlegst?
Also: Prinzipiell ist so, dass eine Datenbank vorliegt und dementsprechend jeder Bericht tatsächlich über den SQL-Server selbst laufen könnte. Willst Du allerdings selbst Abfragen schreiben liegt das Problem darin dass nicht alle Informationen in der Datenbankstruktur wiedergefunden werdne können. Falsch, könne sie natürlich, Du musst nur wissen wo was liegt. Ich weiß jetzt gerade die Tabellennamen und Inhalte nicht auswendig. Ich weiß aber dass Du nicht alle Informationen zu einem Thema (Adressen/Artikel...) in einer Tabelle hast.
Zum Geschwindigkeitsproblem. Wenn Du den TraceLog gestartet hast siehst Du ja welche SQL-Befehle durch den Client abgefeuert werden. Wie ist die Performance wenn Du diese Statements direkt im SQL-Server ausführst? Lahmt das dann auch?
Eventuell wäre es hilfreich wenn Du Sichten im SQL-Server anlegst?
Ich wage zu behaupten bei der DB Maschine, sind die paar Selects kein Problem.
Access ist hier das Problem würde ich meinen bzw. dieser AC-Client wahrscheinlich kommt der mit dem Rendern des ganzen Dinges einfach nicht hinterher.
Access ist hier das Problem würde ich meinen bzw. dieser AC-Client wahrscheinlich kommt der mit dem Rendern des ganzen Dinges einfach nicht hinterher.
Habe bereits den Trace laufen lassen... der SQL Server scheint gelangweilt, es kommen in großen Abständen Abfragen, die restliche Zeit idled er herum, während das MSACCESS.EXE Programm auf dem Terminal Server sich in Richtung 1 GB RAM Nutzung aufmacht... daher denke ich auch es ist und bleibt ein Access Problem... leider wird die Geschichte direkt über den SQL Server nicht so gut funktionieren, da die User ja die Berichte abfragen zu welcher Zeit Sie wollen und da die Parameter in Sage gewählt werden, also die Vorfilter fällt mir da irgendwie kein anderer vernünftiger Weg ein.
Plant Microsoft nicht Access mal leistungsfähiger zu machen? :D
Plant Microsoft nicht Access mal leistungsfähiger zu machen? :D
Access war nie und wird nie ein frontend fürs Enterprise Umfeld werden, mach dir da also nicht zuviel Hoffnungen.
Nochmal zum Bericht. also ich sage nun mal es gibt einen Bericht Umsatz.
Parameter, die man in dem Programm wählt Datum von Montag bis Heute, für Abteilung Absatz Kinderspielzeug, für Kundengruppe 30-40 Jahre, in Zone Bayern richtig?
All diese Sachen stecken doch sowieso in der Datenbank und können als Parameter entsprechend verwendet werden, in der Abfrage für den Bericht steht dann bei
Where Abteilung_id = @abteilung statt z.b. = 16
Und irgendwo auf drm Server gibt es dann entsprechend eine Relation in der alle Abteilungen mit ihren IDS stehen,
das bildet dann den Parameter der Klartext Name der Abteilung im frontend für die user und als wert wird die id in die querys gepackt.
Es gibt keine Datenbank, die man nicht mit sich selbst auswerten kann, zumindest keine relationale.
Dein Programm macht eigentlich exakt das gleiche wie die reporting Services nur mit für große Daten ungeeigneten Mitteln.
Gruß
Nochmal zum Bericht. also ich sage nun mal es gibt einen Bericht Umsatz.
Parameter, die man in dem Programm wählt Datum von Montag bis Heute, für Abteilung Absatz Kinderspielzeug, für Kundengruppe 30-40 Jahre, in Zone Bayern richtig?
All diese Sachen stecken doch sowieso in der Datenbank und können als Parameter entsprechend verwendet werden, in der Abfrage für den Bericht steht dann bei
Where Abteilung_id = @abteilung statt z.b. = 16
Und irgendwo auf drm Server gibt es dann entsprechend eine Relation in der alle Abteilungen mit ihren IDS stehen,
das bildet dann den Parameter der Klartext Name der Abteilung im frontend für die user und als wert wird die id in die querys gepackt.
Es gibt keine Datenbank, die man nicht mit sich selbst auswerten kann, zumindest keine relationale.
Dein Programm macht eigentlich exakt das gleiche wie die reporting Services nur mit für große Daten ungeeigneten Mitteln.
Gruß
Ja, ich gebe Dir vollkommen Recht. Wir haben jedoch noch einen Bericht, der als Addin vom Developer Partner programmiert wurde, der eine Excel Tabelle mit Formatierungen und Formeln erstellt, also Feld für Feld schreibt, nachdem er die Daten aus der SQL Datenbank zusammengezogen hat. In diesem Fall geht das wohl nicht anders.... ich werde es für die anderen "Standard" Berichtabfragen aber mal probieren. Kann man das über ein SQL Tool einem Anwender zur Verfügung stellen oder ist das schwierig?
Die Reporting Services einrichten ist relativ einfach, SQL-Server CD rein und das Feature nachinstallieren auf dem SQL-Server, falls nicht installiert.
Danach kannst du den konfigurieren über die Reporting Services Konfiguration, und das Ding ist erreichbar über eine Webseite, ich glaube als Standard
gilt hier http://HOSTNAME/IP/Berichte, du kannst ggf. auch einen anderen Port konfigurieren, falls du port 80 in Benutzung hast.
Erstellt werden Berichte über das Visual Studio, falls du dahingehend weitere Fragen hast, meld dich am besten mit einer konkreten Fragestellung per neuem Thread oder per PM, das sprengt hier sicherlich den Rahmen.
Danach kannst du den konfigurieren über die Reporting Services Konfiguration, und das Ding ist erreichbar über eine Webseite, ich glaube als Standard
gilt hier http://HOSTNAME/IP/Berichte, du kannst ggf. auch einen anderen Port konfigurieren, falls du port 80 in Benutzung hast.
Erstellt werden Berichte über das Visual Studio, falls du dahingehend weitere Fragen hast, meld dich am besten mit einer konkreten Fragestellung per neuem Thread oder per PM, das sprengt hier sicherlich den Rahmen.
Die Ursache liegt darin, dass Sage Office Line nur eine Access DatenbankAnwendung ist.
Die Sage Office Line stellt ein nettes Frontend für einen MS Access Kern bereit.
Access greift über eine ODBC Verbindung auf den MS SQL Server zu.
Siehe: http://msdn.microsoft.com/de-de/library/bb979206.aspx
Je nach dem wie die Abfragen gestrickt sind, werden die Abfragen auf den SQL Server oder in deinem Fall, in der Userumgebung des Terminalservers ausgeführt.
Bildlich gesprochen lädt Access die Datenbanktabellen vom SQL Server in den Arbeitsspeicher des Terminalservers und wertet sie dort aus.
Wir kennen das Problem auch. Die CPU Auslastung auf unseren Terminalservern liegt häufig im oberen Bereich, während der SQL Datenbankserver kaum eine Regung zeigt.
Wieviele User arbeiten auf dem Terminalserver?
Die Sage Office Line stellt ein nettes Frontend für einen MS Access Kern bereit.
Access greift über eine ODBC Verbindung auf den MS SQL Server zu.
Siehe: http://msdn.microsoft.com/de-de/library/bb979206.aspx
Je nach dem wie die Abfragen gestrickt sind, werden die Abfragen auf den SQL Server oder in deinem Fall, in der Userumgebung des Terminalservers ausgeführt.
Bildlich gesprochen lädt Access die Datenbanktabellen vom SQL Server in den Arbeitsspeicher des Terminalservers und wertet sie dort aus.
Wir kennen das Problem auch. Die CPU Auslastung auf unseren Terminalservern liegt häufig im oberen Bereich, während der SQL Datenbankserver kaum eine Regung zeigt.
Wieviele User arbeiten auf dem Terminalserver?
Hi,
ja, genau so ist es bei uns. Auf einem Terminal Server sind ca. 8 User.... CPU und RAM mässig passt das, da selten alle gleichzeitig irgendwelche Berichte ziehen. Es ist leider auch nicht schneller ,wenn ich es in den Abendstunden teste.... liegt wohl wirklich an der Access Geschichte.
ja, genau so ist es bei uns. Auf einem Terminal Server sind ca. 8 User.... CPU und RAM mässig passt das, da selten alle gleichzeitig irgendwelche Berichte ziehen. Es ist leider auch nicht schneller ,wenn ich es in den Abendstunden teste.... liegt wohl wirklich an der Access Geschichte.
