Announcement

Collapse
No announcement yet.

Umlaute (Konvertierung von ascii nach dbf)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Umlaute (Konvertierung von ascii nach dbf)

    Hallo,
    für den Zugriff auf eine Text Datei habe ich eine SCHEMA Datei erstellt, wie in der Borland Technical Information TI 2844 beschrieben.
    Als CharSet ist ascii eingetragen. Leider werden die Umlaute nicht konvertiert. In der Textdatei sind z.B. für ü > FC, ä > E4, ö > F6 u.s.w.
    eingetragen. Wird die Datei ohne SCHEMA aufgerufen, werden die ersten 256 Zeichen des Datensatzes und die Umlaute richtig dargestellt.
    Welche Möglichkeiten gibt es noch für den Zugriff und die Umwandlung in eine DBase Datei?
    Gibt es bei CharSet noch weitere Parameter?

  • #2
    Ich setze SCHEMA-Dateien häufig ein, und zwar mit gutem Erfolg: allerdings für reine ASCII-Dateien. Darunter verstehe ich solche Textdateien, die in MS-DOS-Umgebung bzw. DOS-Fenster von Windows erstellt wurden. Nur für solche Dateien funktioniert der Zugriff per Schema-Datei. <br>Für reine Text-Dateien der Windows-Plattform wird ein anderer Zeichensatz verwendet - der Zugriff per Schema-Datei funktioniert nicht mehr.<br><br>In der Schema-Datei wird für den Parameter CHARSET=ASCII verwendet. Es ist mir leider nicht bekannt - und auch auf den Borland-Infos nicht ersichtlich - ob hier noch andere Parameter verwendet werden können.<br>Um eine Windows-Text-Datei in eine DOS-Text-Datei zu konvertieren könnte diese z.B. mit WinWord geöffnet werden und als "MS-DOS-Text" gespeichert werden. Mit dieser Datei sollte der Zugriff auch auf Sonderzeichen korrekt erfolgen

    Comment


    • #3
      Hallo,

      kann mir jemand verraten wo ich das Kapitel TI 2844 finden kann??

      Gruss

      Ola

      Comment


      • #4
        Hallo,

        auf der Community-Webseite von Borland (<i>http://community.borland.com/homepage</i>) gibt es einen Ordner <i>Download</i>, dort können alle FAQs und TIs (Technical Information) als ZIP-Datei heruntergeladen werden

        Comment


        • #5
          Hallo,

          ich danke!

          Gruss

          Ola

          Comment


          • #6
            Hallo,

            ich bin mir sicher, dass ich nerve! Aber ich habe mir TIs runter geladen und den oben genannten Artikel nicht gefunden. Kann mir jemand diesen Artikel mailen?? ([email protected])

            Ich danke schon einmal im Voraus...

            Ola

            Comment


            • #7
              <b>TI 2844</b> (Borland Technical Information)

              Delphi (and the BDE) has the capability to use ASCII files to a limited degree as tables. The ASCII driver has the capability to translate the data values in an ASCII fixed-length field or a comma-delimted file into fields and values that can be displayed through a TTable component. How this translation of the ASCII file takes place depends on an accompanying schema file. The schema file for an ASCII data file defines various attributes necessary for parsing the ASCII data file into individual field values. The field definitions for an ASCII fixed-length field file is relatively straightforward, the offsets of various fields in the ASCII file being consistent across all rows in the file. However, for commadelimited files, this process is slightly more complicated due to the fact that not all data values in such a file may be the same length for all rows in the file. This article, then, concentrates on this more difficult task of reading data from comma-delimited, or varrying-length field, files.

              <b>The Schema File</b>

              The schema file for an ASCII data file contains information that defines both the file type (comma-delimited versus fixed-length field), as well as defining the fields that are represented by the data values in each row of the ASCII data file. (All of the settings used in a schema file are case insensitive, so "ascii" is just as valid as "ASCII".) In order that a schema file be recognized as such, it must have the same filename as the ASCII data file for which it provides definitions, but with the filename extension .SCH (for SCHema). The attributes that describe the file are:

              File name: Enclosed in square brackets, this setting specifies the name of the ASCII data file (sans the filename extension, which must be .TXT).

              Filetype: Specifies whether the ASCII data file is structured as a fixed-length field file (use a setting of FIXED) or a commadeelimited file (with data values of potentially varying length (use a setting of VARYING).

              Delimiter: Specifies the character that surrounds String type data values (typically, the double quotation mark, ASCII decimal 34).

              Separator: Specifies the character that is used to separate individual data values (typically, a comma). This character must be a visible character, i.e., cannot be a space (ASCII decimal 32).

              CharSet: Specifies the language driver (use a setting of ASCII).

              Following the file definition settings are field definitions, one for each data value on each row of the ASCII data file. These field definitions supply the information Delphi and the BDE will need to create a virtual field in memory to hold the data value, that virtual field's data type which will affect how the value is translated after being read from the ASCII file, and size and positioning attributes. The various seettings that will appear in each field definition are:

              Field: Virtual field name, will always be "Field" followed by an integer number representing that field's ordinal position in respect to the other fields in the ASCII data file. E.G., the first field is Field1, the second Field2, and so on.

              Field name: Specifies the display name for the field, which appears as the column header in a TDBGrid. Naming convention for ASCII table fields follows that for Paradox tables.

              Field type: Specifies the data tyoe BDE is to use in translating the data value for each field and tells Delphi what type of virtual field to create.
              <pre>
              Use the setting For values of type
              --------------- ----------------------
              CHAR Character
              FLOAT 64-bit floating point
              NUMBER 16-bit integer
              BOOL Boolean (T or F)

              LONGINT 32-bit long integer
              DATE Date field.
              TIME Time field.
              TIMESTAMP Date + Time field.

              </pre>
              (The actual format for date and time data values will be determined by the current setting in the BDE configuration, Date tab page.)

              Data value length: Maximum length of a field's corresponding data value. This setting determines the length of the virtual field that Delphi creates to receive values read from the ASCII file.

              Number of decimals: Applicable to FLOAT typpe fields; specifies the number of digit positions to the right of the decimal place to include in the virtual field definition.

              Offset: Offset from the left that represents the starting position for the field in relation to all of the fields that preceed it.

              For example, the field definition below is for the first field in the ASCII table. It defines a String type data value with a name of "Text", a maximum data value length of three characters (and the field will appear as only three characters long in Delphi data-aware components such as the TDBGrid), no decimal places (a String data value will never have any decimal places), and an offset of zero (because it is the first field and there would not be any preceeding fields).

              Field1=Text,Char,3,00,00

              Here is an example of a schema file with three fields, the first of String type and tthe second and third of type date. This schema file would be contained in a file named DATES.SCH to provide file and field definitions for an ASCII data file named DATES.TXT.
              <pre>
              [DATES]
              Filetype=VARYING
              Delimiter="
              Separator=,
              CharSet=ascii
              Field1=Text,Char,3,00,00
              Field2=First Contact,Date,10,00,03
              Field3=Second,Date,10,00,13
              </pre>
              This schema defines a comma-delimited field where all String type data values can be recognized as being surrounded by the double quotation mark and where distinct data values are separated by commas (excepting any commas that may appear within the specified delimiter, inside individual String data values). The character field has a length of three characters, no decimal places, and an offset of zero. The first date field has a length of 10, no decimals, and an offset of three. And the second date field has a length of 10, no decimals, and an offset of 13.

              For reading ASCII comma-delimited files, the length and offset parameteers for the field definitions do not apply to data values in the ASCII files (as is the case for fixed-length field files), but to the virtual fields, defined in the application, into which the values read will be placed. The length parameter will need to reflect the maximum length of the data value for each field -- not counting the delimiting quotation marks or the comma separators. This is most difficult to estimate for String type data values as the actual length of such a data value may vary greatly from row to row in the ASCII data file. The offset parameter for each field will not be the position of the data value in the ASCII file (as is the case for fixed-length field files), but the offset as represented by the cumulative length of all preceding fields (again, the defined fields in memory, not the data values in the ASCII file.

              Here is a data file that would correspond to the schema file described above, in a file named DATES.TXT:
              <pre>
              "A",08/01/1995,08/11/19955
              "BB",08/02/1995,08/12/1995
              "CCC",08/03/1995,08/13/1995
              </pre>
              The maximum length of an actual data value in the first field is three ("CCC"). because this is the first field and there are no preceding fields, the offset for this field is zero. The length of this first field (3) is used as the offset for the second field. The length of the second field, a date value, is 10, reflecting the maximum length of a data value for that field. The accumulated length of the first and second fields are then used as the offset for the third field (3 + 10 = 13) .

              It is only when the proper length for the data values in the ASCII file are used and each fields length added to any preceding fields to produce offset values for succeeding fields that this process will correctly read the data. If data is misread because of improper length settings in the schema file, most values will suffer adverse translation effects, such as truncation of character data or numeric values being interprreted as zeros. Data will usually still be displayed, but no error should occur.
              However, values that must be in a specific format in order to be translated into the appropriate data type will cause errors if the value read includes characters not valid in a date value. This would include a date data value which, when incorrectly read may contain extraneous characters from other surrounding fields. Such a condition will result in a data translation exception requiring an adjustment of the field length and offset settings in the schema file.
              &#10

              Comment


              • #8
                Nachtrag zu den Schema-Dateien:

                Als Charset sind mir bisher 3 verschiedene Möglichkeiten bekannt,
                um TXT-Dateien nach Paradox-db zu übertragen.
                1. ansiintl (Vorteil: Umlaute wie Ö werden korrekt übertragen)
                2. ascii
                3. intl

                Grüße, Carste

                Comment


                • #9
                  Hallo Leute,

                  mal eine Frage zum umgekehrten Weg. Ich habe eine Paradox-Tabelle und möchte daraus ein Delimited-Textfile erstellen. Als Trennzeichen sollte ein ";" verwendet werden.

                  Benutze ich nun eine TTable-Komponente (TableType: ttASCII) und ein TBatchMove-Objekt, so legt Delphi beim Ausführen des Copyvorgangs automatisch ein "*.sch"-File an, ohne daß man das Trennzeichen angeben kann.

                  Hat hierzu jemand eine Lösung parat ?

                  Grüsse,
                  Carste

                  Comment


                  • #10
                    Hallo Carsten,

                    TBatchMove.Mode auf batAppend setzen, dann wird ein vordefiniertes *.sch-File berücksichtigt.

                    Grüsse,Aloi

                    Comment


                    • #11
                      Hallo Leute,

                      @ Posting 9 (Alois):
                      Ja danke, das funktioniert.

                      Habe nun ein neues Problem mit dem Einlesen einer Text-Datei.

                      In dem sch-File steht folgendes:
                      Field9=TEST,Short Integer,3,00,82

                      Sehe ich mir jedoch nach dem Import der Textdatei die Strukturinfo der Tabelle an, so sehe ich, daß das Feld kein "Short Integer" ist, sondern ein Character.

                      Warum funktioniert dies nicht mit Short Integer ? Muß man was dabei beachten ?

                      Grüsse,
                      Carste

                      Comment


                      • #12
                        Hallo Carsten,
                        ich denke, TBatchMove unterstützt nicht alle Feldtypen, die Paradox kennt. In Deinem Fall wirst Du wohl LONGINT nehmen müssen.
                        Mehr dazu in Beitrag #6 von Andreas Kosch.

                        Grüsse, Aloi

                        Comment


                        • #13
                          @ Posting 11 (Alois):

                          Bei LongInt erhält man für das Feld ein "Integer"-Wert. Ich habe es folgendermaßen gelöst. Man kann noch als Typ "Integer" angeben.

                          Field9=TEST,Integer,3,00,76

                          Ob man nach Integer eine 3, 4 oder 10 eingibt, scheint dabei keine Rolle zu spielen, oder ?

                          Resultat der Strukturinfo:
                          Das Feld "TEST" ist nun ein "Short Integer"-Feld.

                          Grüsse,
                          Carste

                          Comment

                          Working...
                          X