AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Suche Datensenitive ExportToExcel-Funktion
Thema durchsuchen
Ansicht
Themen-Optionen

Suche Datensenitive ExportToExcel-Funktion

Ein Thema von Jumpy · begonnen am 3. Jul 2012 · letzter Beitrag vom 4. Jul 2012
Antwort Antwort
Seite 2 von 2     12   
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.736 Beiträge
 
Delphi 6 Enterprise
 
#11

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 09:01
Stimme als TE omata i. Iwo Asnet zu. Der Einwurf ist gerechtfertigt. Wir haben hier u.a. auch ein komplexes Framework für Excel, mit dem man komfortabel Reports generieren kann. Nur passt das für diese Anwendung nicht so ganz. Es handelt sich um ein internes Programm, mit dem man SQL-Statements zusammenbauen und speichern und verwalten kann. Hier kam der Wunsch auf, dass man gelegentlich die durch das gerade gebaute Statement erstellte Datenmenge (via Grid angezeigt) auch mal exporieren können sollte. CSV-Export war schnell umgesetzt und läuft super schnell. Dagegen ist der Excel-Ole-Export wirklich eine Schnecke, aber man will die Daten ja in Excel haben. Daher geh ich jetzt den o.g. Weg und schau jetzt mal, wie ich es formatiert kriege.

Ich denke aber auch mal drüber nach, ob man unser Excel-Framework so erweitern kann, dass man einem vorbereiteten Report ein SQL-Statement übergibt und Excel von da aus weiterarbeitet.

Experimetiere jetzt mal mit dem Formatieren weiter und meld mich dann mal, was bei rausgekommen ist.
Ralph
  Mit Zitat antworten Zitat
tgvoelker

Registriert seit: 9. Sep 2002
Ort: Oelsnitz, Vogtland
43 Beiträge
 
Delphi 12 Athens
 
#12

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 09:38
Das Problem liegt in der Implementierung: Excel erwartet für Range.Value eine Variante. Wenn Du einen String übergibst, dann wandelt den die Excel-Logik um - und das führt zu den beschriebenen Problemen.

Ich hatte das Problem bei TJVGExportExcel aus JVCL Globus, da war genau so vorgegangen worden.

Die lösung war, die Source zu ändern:

Code:
            if ForceTextFormat or
               (Dataset.Fields[I].Datatype in [ftString,ftMemo,ftFmtMemo,ftFixedChar,ftWideString,ftGuid
                                             ,ftFixedWideChar,ftWideMemo,ftBoolean,ftVariant,ftUnknown
                                             ,ftBytes,ftVarBytes,ftBlob,ftGraphic,ftParadoxOle
                                             ,ftDBaseOle,ftTypedBinary,ftCursor,ftADT,ftArray,ftReference
                                             ,ftDataSet,ftOraBlob,ftOraClob,ftInterface,ftIDispatch,ftOraInterval
                                             ,ftConnection,ftParams,ftStream])or
               (Dataset.Fields[I].IsNull) then Sheet.Cells[RecNo, ColNo + I] := GetFieldValue(DataSet.Fields[I])
            Else Sheet.Cells[RecNo, ColNo + I].Value :=GetFieldValueVar(DataSet.Fields[I]);
In der ursprünglichen Implementierung wurde nur die Funktion GetFieldValue aufgerufen:

Code:
function TJvgCommonExport.GetFieldValue(const Field: TField): string;
begin
  if jeoOutputFormattedStrings in Options then
    Result := Field.DisplayText
  else
    Result := Field.AsString;
  if Assigned(FOnExportField) then
    FOnExportField(Self, Field, Result);

  if FTransliterateRusToEng then
    Result := Transliterate(Result, True);

  if (FMaxFieldSize > 0) and (Field.DataType in [ftString, ftMemo, ftFmtMemo]) then
    if Length(Result) > FMaxFieldSize then
      Result := Copy(Result, 1, FMaxFieldSize) + '...';
end;
Konkret tritt das Problem bei Gleitkommazahlen und BCD auf, weil bei Field.AsString ein Punkt ausgegeben wird, anstelle eines Komma. Die Funktion GetFieldValueVar übergibt daher eine Variante:

Code:
function TJvgCommonExport.GetFieldValueVar(const Field: TField): Variant;
//Erweiterung zum korrekten export von Nicht-Zeichenkettendaten.
var i:Int64;d:DWord;
begin
  if jeoOutputFormattedStrings in Options then Begin
    Result := Field.DisplayText;
    Exit;
  End;
  if Field.DataType in [ftSmallint,ftInteger,ftWord,ftAutoInc,ftShortint,ftByte] then Result:=Field.AsInteger
  Else if Field.Datatype=ftLargeint Then Result:=Field.Value
  Else if Field.DataType=ftLongWord Then Begin
    d:=Field.Value;
    i:=d;
    Result:=i;
  End Else if Field.DataType in [ftFloat,ftExtended] Then Result:=Field.AsExtended
  Else if Field.DataType = ftCurrency Then Result:=Field.AsCurrency
  Else if Field.DataType in [ftBCD,ftFMTBcd] Then Result:=BcdToDouble(Field.AsBCD)
  Else if Field.DataType in [ftDate,ftTime,ftDateTime,ftTimeStamp,ftOraTimeStamp] Then Result:=Field.AsDateTime
  Else Result:=Null;
//  if Assigned(FOnExportField) then FOnExportField(Self, Field, Result); //Abgeschaltet, da hier zwingend ein String erwartet wird.
end;
Allerdings ist hier anzumerken, daß der export von 16T Tupeln mit 60 Spalten ewig dauerte - nach 2 Stunden habe ich den abgebrochen. Verwende nun die Native Excel Suite, da ist der Export dieser Datenmenge nach 20 Sekunden fertig.
Thomas Völker
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#13

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 09:59
Wer in Gottes Namen benötigt 16 Tausend Zeilen mit je 60 Werten?
  Mit Zitat antworten Zitat
tgvoelker

Registriert seit: 9. Sep 2002
Ort: Oelsnitz, Vogtland
43 Beiträge
 
Delphi 12 Athens
 
#14

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 10:28
Rechnungsdaten aus einem Geschäftsjahr.
Thomas Völker
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.736 Beiträge
 
Delphi 6 Enterprise
 
#15

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 11:46
Eine Frage zu #12:

Einmal wird der Zelle etwas zugewiesen via:

Sheet.Cells[RecNo, ColNo + I] :=

im anderen Fall via

Sheet.Cells[RecNo, ColNo + I].value :=

Warum?
Afaik ist .value die Default-Property des Range-Objectes, somit sind die beiden Zuweisungen (auf der linken Seite!) doch gleichwertig, oder?
Ralph
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#16

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 12:19
Rein theoret. hast du recht, aber in der Praxis empfehle ich .Value da Excel und Word sich manchmal nicht an die Theorie halten.


Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
tgvoelker

Registriert seit: 9. Sep 2002
Ort: Oelsnitz, Vogtland
43 Beiträge
 
Delphi 12 Athens
 
#17

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 12:27
Theoretisch schon. Mein erster Ansatz war daher auch, die "Sonderbehandlung" String/sonstiges nicht durchzuführen, sondern grundsätzlich als Variant zu übergeben. Dabei hatte ich aber das Problem, daß die Zellen, an die Strings übergeben wurden, einfach leer blieben. Im nächsten Schritt habe ich dann den alten Code wieder reingenommen und eine Sonderbehandlung für alles gemacht, das ich nicht als String übergeben wollte. Ich erinnere mich auch dunkel, daß ich zunächst versucht hatte, die Varianten an die Range zuzuweisen und das nicht funktionierte - weshalb ich dann .value verwendete.

Wäre das Zeitverhalten akzeptabler gewesen, dann hätte ich weitergemacht damit, die nächsten Schritte wären dann gewesen, daß Zeichenkettenfelder grundsätzlich im Excel hart als Zeichenkette formatiert worden wären (damit z.B. keine führenden Nullen weggemacht werden) und nur eine Funktion zu verwenden (schätze mal, das Excel mit dem Stringformat, welches ich ursprünglich in der Variante übergeben hatte, nicht klarkam - das wäre also ebenso anzupassen). Und natürlich, um das Zeitverhalten zu verbessern, die Übergabe das Daten Zeilenweise in einem varianten Array. Aber wie schon gesagt war das Ding so langsam, daß ich mich umorientieren mußte und das auch tat.

Edit: KH, das ist sogar ein Feature: in Abhängigkeit der Ausprägung des Range-Objekts variiert die default property. Auch wenn "Daily dose of Excel" hier: http://www.dailydoseofexcel.com/arch...trange-object/

schreibt, das läge am VBA-Parser, so bin ich eher der Ansicht, daß das implementiert wurde (warum auch immer) und zudem versionsabhängig ist.
Thomas Völker

Geändert von tgvoelker ( 4. Jul 2012 um 12:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#18

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 12:54
.. und zudem versionsabhängig ist.
Das kann man im Zusammenhang mit Word und Excel nicht laut genug betonen.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Iwo Asnet

Registriert seit: 11. Jun 2011
313 Beiträge
 
#19

AW: Suche Datensenitive ExportToExcel-Funktion

  Alt 4. Jul 2012, 13:16
Es scheint sowohl eine Diskussion um Formatierung und dieses leidige "EXCEL ist klüger als Du und daher interpretiert es für dich die Daten" zu sein.

Ich empfehle die Verwendung von nativen BIFF-Writerklassen. Einige sind Freeware, andere kosten etwas. Prüfe doch, ob die Freewarekomponenten nicht ausreichend sind, deine Bedürfnisse zu erfüllen. Einge XLS-Writer basieren jedoch auf OLE, die kannst Du gleich vergessen.

Wenn man vor dem Problem steht, 2 Stunden auf die Erzeugung einer großen EXCEL-Datei zu warten (z.B. als Basis für BI-Auswertungen), dann wäre z.B. folgende Vorgehensweise relativ schnell umzusetzen und dürfte performant genug sein:
1. CSV-Datei erzeugen
2. EXCEL als OLE starten, CSV einlesen und formatieren
3. Speichern und fertig

Das ist ratzfatz umgesetzt und sollte brauchbare Ergebnisse liefern

Klar, ein Sheet mit 16k Daten als BI-Rechenbasis für die Geschäftsleitung muss schon nach was aussehen, aber so richtig interessiert sich kaum jemand für die einzelnen Daten.

Ich würde ein EXCEL Template erstellen, das alle Auswertungen bereitstellt, die Rohdaten (CSV) auf Sheet999 per OLE einlesen, hübsch machen (per Makro) und den Klotz speichern. Im Template kann man nachträglich das 'Hübschmachenmakro' erweitern, verändern etc.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:56 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz