MSSQL-Server für Debian (Datenbanken und Verzeichnisdienste)

[thread]21473[/thread]

MSSQL-Server für Debian

Tags: perl5 Ähnliche Threads

Leser: 6

Articles: hide open all | hide show old branches

Teilbaum:
MSSQL-Server für Debian (15 Artikel) 2023-08-09 17:54

+16 replies
GwenDragon

2023-07-24 11:52

User since
2005-01-17
14563 Artikel
Admin1

Wenn ich wüsste, woher ich dein Server-Version für Debian-Linux bekomme, würde ich das ja mal gern testen.
Hast du eine Quelle?

//EDIT: Gefunden; https://learn.microsoft.com/en-us/sql/linux/quicks...
Last edited: 2023-07-24 13:19:37 +0200 (CEST)
die Drachin, Gwendolyn

Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
- +15 replies
- Gast stefan
  
  2023-07-24 14:08
  
  Hi,
  hatte vergessen, dass es mittlerweile ja auch Linux-Versionen vom MSSQL gibt. :)
  
  Mehr Hintergrund:
  Es handelt sich um die Datenbanken von "MS Dynamics 365 Business Central" in einer onPrem Installation (Version BC220).
  Die MSSQL Server laufen auf Windows Server V2019 Datacenter V10.0.17763
  
  Das grundlegend mal nachzustellen sollte möglich sein.
  Ich bin leider kein Serveradmin, da fehlt mir das Wissen über die vielen Einstellungen.
  
  Schwierig wird's, wenn man das Produktivsystem nachstellen will... Versionen und Patchstände von Win- und SQL-Server und SQL bzw. DB Einstellungen...etc. Da müssen dann die einzelnen Admins dazu.
  
  Sobald Zeit (Mitte August) werde ich das Clientseitig mit einer frischen Debian 11 erstmal weiter testen.
  Last edited: 2023-07-24 14:50:51 +0200 (CEST)
  - +14 replies
  - GwenDragon
    
    2023-07-24 16:26
    
    User since
    2005-01-17
    14563 Artikel
    Admin1
    
    Bracuhste nicht zu testen.
    Ich schrieb ja schon, dass es auch bei mir auf Debian 11 nicht klappt.
    Ich denke, dass DBD::ODBC veraltet/defekt ist.
    die Drachin, Gwendolyn
    
    Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
    - +13 replies
    - Gast stefan
      
      2023-07-25 08:21
      
      OK, Danke.
      Dann schau ich mal, wie ich das dem Modulentwickler melden kann.
      Last edited: 2023-07-25 09:01:25 +0200 (CEST)
      - +12 replies
      - GwenDragon
        
        2023-07-25 10:40
        
        User since
        2005-01-17
        14563 Artikel
        Admin1
        
        Das Modul ist wohl aber verwaist.
        
        Quote
        Why not adopt me?
        This distribution is up for adoption! If you're interested then please contact the PAUSE module admins via email.
        https://metacpan.org/pod/DBD::ODBC
        
        Aber versuche doch mal auf https://github.com/perl5-dbi/DBD-ODBC/issues einen Kontakt zu bekommen und den Bug zu melden.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +11 replies
        
        Gast stefan
        
        2023-07-27 10:22
        
        Danke für die Info.
        Da fehlen mir die Grundlagen wie GIT mit CPAN zusammenhängt -
        oder ist das unabhängig ein fork - wenn ja, warum?
        
        Ich habe bei dem Problem noch eine Beobachtung gemacht:
        Lege ich das Script in cgi-bin und rufe es über Apache auf,
        kommen die Feldnamen korrekt.
        Wie kann das denn sein???
        
        Außerdem muss das script in latin1 vorliegen.
        Bei utf8 (mit oder ohne "use utf8")
        fürt ein Umlaut in der SQL zu einem SQL-Fehler z.B. "Invalid column name 'Auftragsbestätigung'"
        Last edited: 2023-07-27 10:29:18 +0200 (CEST)
        
        GwenDragon
        
        2023-07-27 11:06
        
        User since
        2005-01-17
        14563 Artikel
        Admin1
        
        Was für ein charset liefert der Apache denn?
        Wo stellst du dann ein dass es Latin1 sein soll?
        
        Wenn es nur mit Latin1 geht, dann benutze halt kein use uft8; im Perl-Programm oder setze am Anfang des Programms no utf8;
        
        Weiter unter http://www.perl-community.de/bat/poard/thread/21473#ms_195200
        Last edited: 2023-07-27 12:01:50 +0200 (CEST)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +9 replies
        
        rosti
        
        2023-07-27 11:11
        
        User since
        2011-03-19
        3219 Artikel
        BenutzerIn
        
        Quote
        Außerdem muss das script in latin1 vorliegen.
        Bei utf8 (mit oder ohne "use utf8")
        fürt ein Umlaut in der SQL zu einem SQL-Fehler z.B. "Invalid column name 'Auftragsbestätigung'"
        
        Offensichtlich speichert MSSQLServer den Feldnamen in Latin1-Kodierung. Da ist da 'ä' ein Byte mit der Wertigkeit E4.
        
        MFG
        
        PS: Ist natürlich auch die Frage über welches Backend die Tabelle erstellt wurde und auf welche Art und Weise da die Feldnamen kodiert wurden.
        
        An dieser Stelle sei mal wieder angemerkt, daß in Sachen Zeichenkodierung natürlich auch die gesamte Übertragung mit eingeht.
        Last edited: 2023-07-27 11:20:08 +0200 (CEST)
        
        +8 replies
        
        Gast stefan
        
        2023-07-27 12:22
        
        Was ich absolut nicht verstehe:
        
        Wenn das gesamte script in latin vorliegt und über die linux console (perl script.pl)
        mit 'SELECT *..
        bei Umlauten zusammengesetzte Feldnamen zurückkommen:
        AuftragsbestätigungGutschrift,
        Gutschrift
        
        Wie kann dasselbe script unter Apache dann die korrekten Feldnamen bringen?
        Auftragsbestätigung,
        Gutschrift
        
        Was ist bei einem Aufruf über Apache anders?
        Die http-Kommunikation (header/zeichensatz) erklärt nicht den jetzt korrekten Feldnamen.
        Sie SQL-Kommunikation läuft doch weiter direkt über das script/odbc
        und Ergebnis wird mit print/say lediglich zurück an den Apache zur Anzeige gegeben
        - oder modifiziert Apache was an der SQL-Kommunikation bzw. macht die evtl. selbst???
        
        Mein Ursprungsproblem ist ja, dass es auf der Console nicht klappt.
        Last edited: 2023-07-27 12:45:31 +0200 (CEST)
        
        +5 replies
        
        GwenDragon
        
        2023-07-27 12:58
        
        User since
        2005-01-17
        14563 Artikel
        Admin1
        
        Der Apache hat als Standard-Charset Latin1 (ISO-8859-1). Perl hat Latin 1.
        Die Shell aber mutmaßlich als modernes Linux UTF-8.
        
        Mach mal in der Shell folgendes:
        
        unset LC_ALL
        unset LANG
        export LANG=de_DE.ISO-8859-1
        export LC_ALL=de_DE.ISO-8859-1
        # dann dein perl-Programm starten.
        Last edited: 2023-07-27 13:13:35 +0200 (CEST)
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +4 replies
        
        Gast stefan
        
        2023-07-27 15:05
        
        Ja, das klappt.
        Habe zwar beim letzten export einen Fehler erhalten, die Feldnamen kommen aber dann korrekt (in latin).
        Die Richtung habe ich verstanden, die genauen Grundlagen muss ich mir noch anlesen.
        
        Hattest Du den DBD::ODBC speziell mit unicode-support auch getestet?
        Muss man mit einem Flag übersetzen lassen.
        
        Ich konnte im C-Code
        https://metacpan.org/release/MJEVANS/DBD-ODBC-1.61...
        in Zeile 2470 wohl die Längenberechung für die Spaltennamen (WITH_UNICODE) finden. (Bin aber kein C-ler)
        
        Kann ich hier leider erst in ca. 14 Tagen testen.
        Evtl. klappt`s ja damit schon
        Last edited: 2023-07-27 15:22:43 +0200 (CEST)
        
        +3 replies
        
        GwenDragon
        
        2023-07-27 17:47
        
        User since
        2005-01-17
        14563 Artikel
        Admin1
        
        Ich hatte DBD::ODBC nicht selbst kompiliert, nur das fertige Modul des Debian11-(Bullseye)-Repos benutzt.
        
        Aber gut das du es lösen kannst. Freut mich.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        +2 replies
        
        Gast Stefan
        
        2023-08-09 16:01
        
        Hallo GwenDragon,
        
        ich konnte eben einen ersten Test mit dem compilierten Modul (Flag unicode-Unterstützung) machen: Die Daten kommen jetzt als unicode zurück und dann tatsächlich mit den korrekten Spaltennamen.
        Leider muss ich dann alle Programme anfassen und die Codierung anpassen.
        Das Repro-Modul hat einfach ein Problem mit utf8, evtl. nehme ich noch Kontakt mit dem GIT-Programmierer auf, dann hätte ich weniger Arbeit.
        
        Vielen Dank für die Unterstützung :)
        Last edited: 2023-08-09 17:53:13 +0200 (CEST)
        
        GwenDragon
        
        2023-08-09 17:54
        
        User since
        2005-01-17
        14563 Artikel
        Admin1
        
        Gratulation.
        Dann kannst du ja weiter arbeiten :-)
        
        Und wir helfen hier gern weiter.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        rosti
        
        2023-07-27 14:52
        
        User since
        2011-03-19
        3219 Artikel
        BenutzerIn
        
        Hi Stefan,
        
        der Webserver kommuniziert mit Perl über STDIN, STDOUT, das ist der Common Gateway im Sinne CGI. Auf diesem Gateway gilt die Bytesemantics, um diese sicherzustellen, setze mal:
        
        Code (perl): (dl )
        
        1 2
        
        binmode STDIN; binmode STDOUT;
        
        in Deinem Perlscript. Evntl. ändert das was. Deine Konsole setzt ebenfalls die Bytesemantics durch, denn Ausgabe ist IO und da gilt Bytesemantics. Was Deine Konsole diesbez. macht kannst Du testen:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
        
        #!/usr/bin/perl use strict; use warnings; binmode STDIN; binmode STDOUT; # Ausgabe der Bytes utf8-kodiertes ä printf("Oktetten ä: %s\n", pack("CC", 0xC3, 0xA4)); # lese STDIN print "Lese aus der Pipe:\n"; while( read(STDIN, my $bin, 1)){ printf "%X\n", unpack("C", $bin); }
        
        Code: (dl )
        
        1 2 3 4 5 6
        
        C:\Users\49162\Desktop>echo ä| perl pack.pl Oktetten ├ñ: ├ñ Lese aus der Pipe: 84 D A
        
        wobei 0xD, 0xA die Bytes für das Ende der Eingabe sind. Das 'ä' selbst wird als ein Byte mit der Wertigkeit 0x84 (dezimal 132) gelesen, UTF-8 ist das nicht sondern Codepage 850.
        
        Guck doch mal wie das bei Dir aussieht.
        
        PS: UTF-8 in der Windows-CMD geht übrigens so:
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9
        
        C:\Users\49162\Desktop>mode con: cp select=65001 Status von Gerät CON: --------------------- Zeilen: 9001 Spalten: 120 Wiederholrate: 31 Verzögerungszeit:1 Codepage: 65001
        
        Und danach sieht Ergebnis meines Scripts so aus:
        
        Code: (dl )
        
        1 2 3 4 5 6 7
        
        C:\Users\49162\Desktop>echo ä|perl pack.pl Oktetten ä: ä Lese aus der Pipe: C3 A4 D A
        
        Wenn wir das haben, können wir sicher sein daß bei einer Eingabe über die Console auch die richtigen utf-8-kodierten Oktetten im Script ankommen.
        Last edited: 2023-07-27 16:54:24 +0200 (CEST)
        
        bianca
        
        2023-07-28 09:17
        
        User since
        2009-09-13
        6978 Artikel
        BenutzerIn
        
        Guest stefan
        Wie kann dasselbe script unter Apache dann die korrekten Feldnamen bringen?
        
        Meinst du damit einen Request mittels Browser gegen den Apache Webserver, der weiter über CGI zum Perlscript und darüber zur DB gelangt?
        Dann sei erwähnt, dass u. U. schon der Browser Request in einer unerwarteten Zeichenkodierung passiert.
        10 print "Hallo"
        20 goto 10

View all threads created 2023-07-21 11:01.