Posted by Sven Thämar

Allgemein/Vorgabe

Unsere Kunden wollten, dass deren Belege (Angebot, Lieferschein, …) in unterschiedlichen Sprachen gedruckt werden können. Die Sprache sollte von außen, dem Modul (Angebot, Lieferschein, …), vorgegeben werden. Unser Ziel war, möglichst nur einen Beleg pro Modul zu verwenden.

Lösung

Wir haben die Funktion “lookup” verwendet.  Die Funktion ist als Ausdruck/Expression “=lookup(“invoice.Artikelnummer”, Fields!rep_key.Value, Fields!rep_label.Value, “DS_Localization”)” in einem Textfeld eingebunden. Damit die Funktion den richtigen Wert liefert muss auf der Datenbank eine Übersetzungstabelle vorhanden sein. Diese Tabelle muss anschließend als DataSet im Bericht eingebunden sein. Im DataSet wird anhand der Where-Bedingung die Sprache selektiert. Diese muss demnach als Parameter mit übergeben werden.

In diesem Fall liefert der “lookup” die Übersetzung dür das Feld “invoice.Artikelnummer” zurück. Die Felder “rep_key” und “rep_label” kommen aus der eingebundenen Tabelle (DataSet “DS_Localization”)

Tabelle

rep_key (Schlüssel)
rep_label (Bezeichnung; Text der gedruckt wird)
rep_local (Sprachschlüssel; EN, DE, FR, …)

Posted by Sven Thämar

Bei meiner letzten Installation von Forms6i unter Windows 7 (64-Bit) gab es plötzlich den Fehler forms60 OS_ERROR. Abhilfe schaft hier die Reuzierung des PATH-Eintrages. Dieser war für eine Form6i Installation zu lang. Am besten auf ca. 800 Zeichen kürzen, vorher sichern(!) und dann noch mal die Installation starten. Dann sollte es funktionieren. Anschließend können die evtl. entfernten PATH-Einträge wieder hinzugefügt werden.

Posted by Sven Thämar

Eine Prüfziffer nach dem Verfahren Modulo 97 zu berrechnen sollte nicht schwer sein. Hierfür gibt es im internet ausreichend Anleitungen.

Was aber oft nicht bedacht wird, ist, das es in Deutschland bei einigen Banken (z.B. Commerzbaank, Deutsche Bank, …) sogennante Hauptkonten gibt. Diese Hauptkonten enden mit einer doppel Null “00″. Hat aber nichts mit dem “Geheimdienst Ihrer Majestät” zu tun. Das Hauptkonto kann bei einer Transaktion mit oder ohne “00″ angesprochen werden. Bei der Ermittlung einer richtigen IBAN kommt aber als Prüfziffer der gleiche Wert raus. Also das Konto 7896543 und 789654300 liefert die gleiche Prüfziffer. Aber nur wenn die Ermittlung über eine Bank läuft. Wird die Ermittlung über ein eigenes Programm gesteuert werden für beide Konten unterschiedliche Prüfziffern gebildet. Das ist zwar mathematisch richtig aber in diesem Fall logisch falsch. Eine 100% Lösung bei der Berechnung gibt es nicht.

Viel Erfolg bei einer SEPA Umstellung.

Posted by Eric Bartels

From one day to the other in all of my current environments I had trouble connecting with RDP via UAG to remote servers. The error message always was “Your computer can’t connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance“.

Its not that clear that the issue is on the client side. So troubleshooting on the UAG-side did not help. Further research and testing revealed the culprit. Microsoft!

After a certain Hotfix, KB2592687 to be precise, the connectivity issues started.

So I did a quick

Get-Hotfix -Id KB2592687

to see if I had the patch installed. And yes it was. So another

cmd.exe /c wusa.exe /uninstall /KB:KB2592687 /quiet

and a lot of waiting and restarting finally allowed a connection via RDP via UAG.
A hotfix for the UAG to allow newer RDP clients is still not available!

Posted by Eric Bartels

In a current project a search based solution is required to allow a research against an existing set of records. Of course the search-backend is the elasticsearch.

This projects requires the use of .Net 3.5 which makes it impossible to use NEST as elasticsearch client.

To at least add a little bit of comfort when writing the queries against the search-cluster I make use of RestSharp for easy connecting and JSON handling. Net 3.5 has no ExpandoObject to create dynamic property names. It took me awhile to find out but a simple Dictionary does the trick.

var innerQueries = new List<object>();
 
// Data is a Dictionar<string, string> where the key is the fieldname used in elasticsearch
// and the value the value to search for (e.g. title => foo; description => baz)
foreach(var token in data.Keys)
{
  dataResult.Add(new
  {
    match_phrase = new Dictionary<string, string>;
    {
      { 
        token,
        data[token]
      }
    }
  });
}
 
var final = new
{
  query = new
  {
    @bool = new
    {
      must = innerQueries
    }
  },
  from = 0,
  size = 250
};

Serializing this into JSON and sending it via RestSharp creates a request with multiple must “clauses” each using a match_prase query.

{
  "query":{
    "bool":{
      "must":[
        {
          "match_phrase":{
            "record.title":"foo"
          }
        },
        {
          "match_phrase":{
            "record.description":"baz"
          }
        }
      ]
    }
  },
  "from":0,
  "size":250
}