Ich habe eine VB.NET-Anwendung kombiniert mit einer MySQL-Datenbank und
verwende LL14. Ich mache mir nun Gedanken sämtliche Reports in der
MySQL-Datenbank zu speichern anstatt die Reportfiles mit der Anwendung
auszuliefern? Gibt es evt. Gründe, welche gegen dieses Vorgehen sprechen? Es
sind momentan zirka 120 Reports, welche durch die Benutzer nicht verändert
werden können.
Die Reports können an List & Label nur in Dateiform übergeben werden.
D.h. du musst vor dem Druck der Reports, diese zunächst aus der
Datenbank als temporäre Datei restaurieren. Im Normalfall wählt der
Anwender über den speziellen List & Label Dialog (Dateiauswahl mit
Vorschau) seinen Report aus. Da dieser aber auf Dateien basiert, kannst
du den in deinem Fall wahrscheinlich nicht nehmen. Ggf. musst du noch
die Druchereinstellungen, welche für den Report in der P-Datei (z.B.
*.lsp) abgelegt werden für jeden Benutzer auch in die Datenbank speichern.
HP
Hallo zusammen
Ich habe eine VB.NET-Anwendung kombiniert mit einer MySQL-Datenbank und
verwende LL14. Ich mache mir nun Gedanken sämtliche Reports in der
MySQL-Datenbank zu speichern anstatt die Reportfiles mit der Anwendung
auszuliefern? Gibt es evt. Gründe, welche gegen dieses Vorgehen
sprechen? Es sind momentan zirka 120 Reports, welche durch die Benutzer
nicht verändert werden können.
Ich habe eine VB.NET-Anwendung kombiniert mit einer MySQL-Datenbank und
verwende LL14. Ich mache mir nun Gedanken sämtliche Reports in der
MySQL-Datenbank zu speichern anstatt die Reportfiles mit der Anwendung
auszuliefern? Gibt es evt. Gründe, welche gegen dieses Vorgehen
sprechen? Es sind momentan zirka 120 Reports, welche durch die Benutzer
nicht verändert werden können.
Wenns um ein einfaches ausliefern geht, oder um den Schutz der Reports
vor den Usern, könntest du die Reports auch als Embedded Resources
direkt in deiner Anwendung speichern.
Ich habe eine VB.NET-Anwendung kombiniert mit einer MySQL-Datenbank und
verwende LL14. Ich mache mir nun Gedanken sämtliche Reports in der
MySQL-Datenbank zu speichern anstatt die Reportfiles mit der Anwendung
auszuliefern? Gibt es evt. Gründe, welche gegen dieses Vorgehen sprechen? Es
sind momentan zirka 120 Reports, welche durch die Benutzer nicht verändert
werden können.
Besten Dank für eure Tipps.
Freundliche Grüsse
Martin Schumacher
ich habe eine Anwendung, die an mehreren Standorten eingesetzt wird. Diese Standorte haben eine 2 MBit-Standleitung zum zentralen Server. Da die Lst-Dateien z.T. mehrere 100 kByte groß sind, würden diese die Leitung sehr beanspruchen. Aus diesem Grund habe ich mich gegen das Vorhalten der Dateien in der DB entschieden.
Besten Dank für den Hinweis. Momentan sind bei mir praktisch keine Reports
über 100 Kbyte gross. Verwendete Grafiken würde ich auch in Zukunft direkt
mit der Anwendung ausliefern. Aber zu vernachlässigen ist der genannte Punkt
sicher nicht.
Danke.
Gruss
Martin
“Steffen Häselbarth” <steffen.haeselbarth@kid-magdebu…> schrieb im
Newsbeitrag news:416741082008113459@combit.net…
Hallo Martin,
Hallo zusammen
Ich habe eine VB.NET-Anwendung kombiniert mit einer MySQL-Datenbank und
verwende LL14. Ich mache mir nun Gedanken sämtliche Reports in der
MySQL-Datenbank zu speichern anstatt die Reportfiles mit der Anwendung
auszuliefern? Gibt es evt. Gründe, welche gegen dieses Vorgehen sprechen?
Es
sind momentan zirka 120 Reports, welche durch die Benutzer nicht
verändert
werden können.
Besten Dank für eure Tipps.
Freundliche Grüsse
Martin Schumacher
ich habe eine Anwendung, die an mehreren Standorten eingesetzt wird. Diese
Standorte haben eine 2 MBit-Standleitung zum zentralen Server. Da die
Lst-Dateien z.T. mehrere 100 kByte groß sind, würden diese die Leitung
sehr beanspruchen. Aus diesem Grund habe ich mich gegen das Vorhalten der
Dateien in der DB entschieden.
Es ist mir bewusst, dass ich die Dateien zuerst wieder umwandeln muss. Dies
klappt eigentlich problemlos. Mir fehlt eher noch ein sauberer Ansatz, dass
allfällige Mutationen der Reports auch wieder in die DB geschrieben werden.
Ich könnte mir vorstellen, dass ich den HASH-Wert des Reports vor dem Öffnen
des Designer und nach dem Schliessen des Designer vergleiche. Gibt es evt.
andere Ansätze? Die Benutzer benötigen übrigens keine Auswahl des Reports.
Diese sind fix vorgegeben. Diese Problematik entfällt also.
Du hast noch einen Punkt angesprochen, welcher mir momentan nicht ganz klar
ist. Welchen Zweck haben die Dateien lsp und ~lst in einem List-Project
genau. Ich habe bis jetzt die Anwendung immer ohne lsp-Datei ausgeliefert,
jedoch mit ~lst. Ich habe keine Reports, welche einen bestimmten Drucker
benötigen.
Gruss
Martin
“Hans Peter Reische” <inftec.soft@freen…> schrieb im Newsbeitrag
news:37488108200885351@combit.net…
Hallo!
Die Reports können an List & Label nur in Dateiform übergeben werden. D.h.
du musst vor dem Druck der Reports, diese zunächst aus der Datenbank als
temporäre Datei restaurieren. Im Normalfall wählt der Anwender über den
speziellen List & Label Dialog (Dateiauswahl mit Vorschau) seinen Report
aus. Da dieser aber auf Dateien basiert, kannst du den in deinem Fall
wahrscheinlich nicht nehmen. Ggf. musst du noch die Druchereinstellungen,
welche für den Report in der P-Datei (z.B. *.lsp) abgelegt werden für
jeden Benutzer auch in die Datenbank speichern.
HP
Hallo zusammen
Ich habe eine VB.NET-Anwendung kombiniert mit einer MySQL-Datenbank und
verwende LL14. Ich mache mir nun Gedanken sämtliche Reports in der
MySQL-Datenbank zu speichern anstatt die Reportfiles mit der Anwendung
auszuliefern? Gibt es evt. Gründe, welche gegen dieses Vorgehen sprechen?
Es sind momentan zirka 120 Reports, welche durch die Benutzer nicht
verändert werden können.
Wie wär’s mit dem Archivbit (dafür ist das eigentlich da) oder dem
Änderungsdatum?
Paulchen
“Martin Schumacher” <news@ruete…> wrote in message
news:37359108200819357@combit.net…
Hallo Hans Peter
Besten Dank für deine Antwort.
Es ist mir bewusst, dass ich die Dateien zuerst wieder umwandeln
muss. Dies
klappt eigentlich problemlos. Mir fehlt eher noch ein sauberer
Ansatz, dass
allfällige Mutationen der Reports auch wieder in die DB geschrieben
werden.
Ich könnte mir vorstellen, dass ich den HASH-Wert des Reports vor
dem Öffnen
des Designer und nach dem Schliessen des Designer vergleiche. Gibt
es evt.
andere Ansätze? Die Benutzer benötigen übrigens keine Auswahl des
Reports.
Diese sind fix vorgegeben. Diese Problematik entfällt also.
Du hast noch einen Punkt angesprochen, welcher mir momentan nicht
ganz klar
ist. Welchen Zweck haben die Dateien lsp und ~lst in einem
List-Project
genau. Ich habe bis jetzt die Anwendung immer ohne lsp-Datei
ausgeliefert,
jedoch mit ~lst. Ich habe keine Reports, welche einen bestimmten
Drucker
benötigen.
Gruss
Martin
“Hans Peter Reische” <inftec.soft@freen…> schrieb im Newsbeitrag
news:37488108200885351@combit.net…
Hallo!
Die Reports können an List & Label nur in Dateiform übergeben
werden. D.h.
du musst vor dem Druck der Reports, diese zunächst aus der
Datenbank als
temporäre Datei restaurieren. Im Normalfall wählt der Anwender über
den
speziellen List & Label Dialog (Dateiauswahl mit Vorschau) seinen
Report
aus. Da dieser aber auf Dateien basiert, kannst du den in deinem
Fall
wahrscheinlich nicht nehmen. Ggf. musst du noch die
Druchereinstellungen,
welche für den Report in der P-Datei (z.B. *.lsp) abgelegt werden
für
jeden Benutzer auch in die Datenbank speichern.
HP
Hallo zusammen
Ich habe eine VB.NET-Anwendung kombiniert mit einer
MySQL-Datenbank und
verwende LL14. Ich mache mir nun Gedanken sämtliche Reports in der
MySQL-Datenbank zu speichern anstatt die Reportfiles mit der
Anwendung
auszuliefern? Gibt es evt. Gründe, welche gegen dieses Vorgehen
sprechen?
Es sind momentan zirka 120 Reports, welche durch die Benutzer
nicht
verändert werden können.