0

Leere Datumsfelder werden nach erneuten Öffnen der DB fälschlicherweise mit 01.01.1970 gefüllt

Ich habe eine DB für Nebenkostenabrechnung erstellt. Darin gibt es Verknüpfungen und Untertabellen, sowie Positionen mit Datumsfeld.
Nicht jede Position wird angesprochen, das Datumsfeld bleibt also leer.
Eigenartigerweise werden nach erneuten Öffnen der DB fälschlicherweise einige (nicht alle) Datumsfelder mit 01.01.1970 gefüllt. Wenn ich das falsche Datum lösche bleibt es erstmal leer, nach erneuten Öffnen der DB steht wieder 01.01.1970 drin.
Randbemerkung: Die Datumsfelder der Eingabetabelle werden aus einer Untertabelle über zwei Verknüpfungen zur Druckausgabe in einem fx-Feld ausgelesen mit z.B. "date('NeKo-Jahr'.'NeKo-Objekt'.'SonstHzg-Datum')"
Wie kann das sein????

31 Antworten

null
    • mgapo
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Nachtrag:

    Dieses Phänomen tritt immer dann auf, wenn in der Haupttabelle (Tabelle der Dateneingabe) ein Datum eingetragen wurde und später wieder gelöscht wurde. Dann steht nach erneuten Öffnen der DB immer der 01.01.1970 drin.     :-((((

    • mirko3
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Hi. Warum es so bei Dir ist, weiß ich so ohne DB-Ansicht auch nicht. Prinzipiell ist Dein Code aber nicht ganz glücklich. Der Rückgabewert ist durch date() zwar ein sichtbares Datum, aber innerhalb der date()-Funktion steht bei Dir ein Array, d.h. Auch wenn es nur ein Datum enthält, ist es vom Typ her ein Array. Besser wäre 

    'NeKo-Jahr'.'NeKo-Objekt'.text('SonstHzg-Datum')
    

    Jetzt kann es sein, dass mehrere Datum zurückgegeben werden.
    Außerdem. Wenn der Wert, der  innerhalb Deiner date()-Funktion z.B. 1 ergibt, dann würde das Datum 01.01.1970 ausgegeben werden, da date() auch Zahlenwerte entgegennimmt. Soviel im Blindflug;-). Mirko

    • truthein
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Das Problem habe ich auch (Ninox Database App 3.7.12 auf Mac) und bin daher per Suche hier auf diesen Forumsbeitrag gestossen.

    Ich habe das mit einem Minimalbeispiel reproduziert: Datenbank mit genau einer Tabelle. Diese hat genau ein Datumsfeld «Datum». Wird dieses mit einem Wert belegt, dann wieder gelöscht und dann die Datenbank geschlossen und wieder geöffnet, so hat das Datumsfeld den Wert «01.01.1970». Das Löschen kann per Hand oder per Scriptbefehl «Datum := null» geschehen.

    Das soll nicht sein. Wie kann das behoben werden? Ein Datumsfeld muss leer sein können.

    • mgapo
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Hallo Mirko, ich habe mal eine neue leere Tabelle angelegt mit einem Datums-Feld und einem T-Feld. Wenn im Datumsfeld ein Datum eingetragen und später wieder gelöscht wird steht nach dem erneuten Öffnen der 01.01.1970 drin, hat also nichts mit der date()-Funktion im fx-Feld zu tun.

    Es handelt sich hier also um einen generischen Bug in Ninox, so wie es auch trut beschrieben hat.

    Hier wären mal die Entwickler am Zug.

    • mirko3
    • vor 1 Jahr
    • Gemeldet - anzeigen

    mgapo trut Hi Ihr beiden. Ich habe es auf allen meinen Plattformen (Mac, Web-Safari, Ipad - neueste Versionen) nachgestellt, kann den Fehler nicht nachvollziehen. Falls einer von Euch den Support informiert  und eine Antwort erhält, wäre ich dankbar für eine Info. 

      • truthein
      • vor 1 Jahr
      • Gemeldet - anzeigen

      Hallo Mirko mgapo . Ich habs dem support geschrieben, kam rasch Antwort: «Wir konnten das Verhalten bereits nachstellen und haben den Fall an unsere Entwickler weitergegeben. Wir hoffen, die Korrektur in naher Zukunft veröffentlichen zu können.» Dort also liess sich das reproduzieren. Speziell, dass bei dir Mirko irgendetwas dieses (Fehl)verhalten verhindert – keine Ahnung, jedenfalls super, dass du das nachgestellt hattest.

      Ich hoffe auf baldigen Fix, da das bei mir hier Probleme verursacht ...

    • UweG
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Wie löscht ihr das Datum-Feld?
    Wenn es mit einer Zahl überschrieben wird um es zu leeren bspw. DatumFeld := 0, dann wird der 01.01.1970 angezeigt.
    Korrekt wäre das Datumfeld mit 'null' zu überschreiben, damit es leer bleibt. 

      • truthein
      • vor 1 Jahr
      • Gemeldet - anzeigen

      So: 

      trut said:
      per Hand oder per Scriptbefehl «Datum := null»

      Es wird mit 'null' überschrieben. Das  passiert aber auch nach Löschen per Hand (etwa mittels der "Löschen" Schaltfläche in der Kalender-Eingabemaske )

    • truthein
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Das soeben erschienene Update auf 3.7.13 hat das nicht behoben.

    • truthein
    • vor 1 Jahr
    • Gemeldet - anzeigen

    Ich habe etwas entdeckt: in einer alten Datenbank passierte das nicht. Unterschied: dort war das "Zeitzonen unabhängige Datum" nicht aktiviert. Nachdem das – irreversibel (!) – aktiviert wird, passiert in der Folge der Fehler.

    Neu angelegte Datenbanken erhalten unabänderbar das  "Zeitzonen unabhängige Datum" aktiviert. Folglich haben sie diesen Fehler.
     

    Das können vermutlich nur die Entwickler beheben. Jedenfalls fällt mir bislang kein Umweg ein, wie ich ein leeres Datumsfeld bekomme ...

    • Axel_Petrak.1
    • vor 10 Monaten
    • Gemeldet - anzeigen

    Das Problem ist nun 6 Monate dem Support bekannt - immer noch keine Fix oder Workaround vom Support ! Sehr traurig 😞 

    wäre super zum Beispiel ein kleines Skript anzubieten, dass wenn das Datum 01.01.1970 ist , das Datumsfeld automatisch gelöscht wird …. könnte man kopieren bis es eine Fix in einer neuen Version gibt. 
     

    oder kann hier Jemand damit helfen ?

    vielen Dank 

      • Ninox-Professional
      • planoxpro
      • vor 10 Monaten
      • Gemeldet - anzeigen

       

      Ein Button-Script, das alle Datumsfelder mit dem Wert 01.01.1970 auf 'null' setzt, könnte bspw. so aussehen:

      let myDate := date(1970, 1, 1);
      (select Datum1970 where Datum = myDate).(Datum := null)
      

      Allerdings nützt das natürlich nichts, wenn das leere Feld, so wie oben beschrieben, nach erneutem Öffnen der Datenbank tatsächlich wieder auf den 01.01.1970 gesetzt wird.

      • truthein
      • vor 10 Monaten
      • Gemeldet - anzeigen

       

      So etwas könnte als «Trigger nach Öffnen» gemacht werden. Immerhin wird das Datumsfeld mit dem Wert 01.01.1970 beim Öffnen der Datenbank so auf «null» gesetzt.

      Das setzt voraus, dass ein solches Datum nie vorkommt (naja ... wird's wohl auch nicht).

      Es muss auch für *jedes* Feld mit Kalenderdaten gemacht werden, von dem man möchte, dass es leer sein kann.

      Ich finde, dieses Verhalten von Datumsfeldern führt zu einem logischen Problem. Jedes Feld eines Datensatzes muss zu beliebigem Zeitpunkt leer sein können. Das ist eine Eigenschaft eines solchen Containers. Das sollte behoben werden.

    • Ninox-Professional
    • planoxpro
    • vor 10 Monaten
    • Gemeldet - anzeigen
     said:
    Das sollte behoben werden.

    So ist es. Je schneller, desto besser. Und das gilt auch bzw. erst recht für alle anderen Probleme mit Datums- und Zeitwerten, die eine ernsthafte Nutzung von Ninox enorm erschweren können.

    • Axel_Petrak.1
    • vor 10 Monaten
    • Gemeldet - anzeigen

    Vielen Dank für die Vorschläge  ! Werde es mal testen - super wäre natürlich, wenn das Problem beseitigt würde - ist ja nun schon über 6 Monate bekannt ! 

    Einen schönen sonnigen Tag ! 

    • Customer Support Ninox
    • uwe_groegor
    • vor 10 Monaten
    • Gemeldet - anzeigen

    Ich habe in der bestehenden Bugmeldung diesen Diskussionsbeitrag angehängt.
    Bei der Meldung eines Fehlers ist es wichtig auch die Systemvoraussetzungen mitzuteilen. 
    In diesem Threat geht zB. aus dem ersten Eintrag nicht hervor, um welche Anwendung es sich handelt.
    Browserzugriff, Mac-App, iOS-App, Android-App.
    Diese Information kommt erst später.
    Auch dass der Fehler nur bei lokal oder in der iCloud gespeicherten Datenbanken auftritt, wird erst im laufe dieses Beitrages ersichtlich.
    Bitte gebt bei Fehlermeldungen soviel Informationen wie möglich, damit Ninox den Fehler eingrenzen und auch nachstellen kann.
    Vielen Dank

      • truthein
      • vor 10 Monaten
      • Gemeldet - anzeigen

      Uwe 

      klar, das ist grundsätzlich ganz richtig und sinnvoll. Vielleicht ist unser Thread hier auch eine zusätzliche Info für die Entwickler, so dass du den angefügt hast.

      ( Ich bin aber doch ganz brav und habe die Angaben in meinem post gemacht. In meiner Mail an den Support waren die Umgebungsvariablen naturgemäss angegeben und der konnte das ja auch reproduzieren - habe ich oben gepostet - https://forum.ninox.de/t/83h0qfl?r=p8h0y3x )

      Wollte noch mitteilen: mittlerweile habe ich eine Mail bekommen, in der steht, dass «[…] Das Fehlverhalten ist auf der To-do liste der Entwickler, kann allerdings aus Prioritätsgründen erst nach wichtigen Updates für die Web App angegangen werden. Wir haben dein Anliegen nicht vergessen und werden es nach dem roll-out unseres großen UI-Updates angehen.»

       

      [Edit: Link zum Post eingesetzt]

      • Maurice
      • vor 3 Monaten
      • Gemeldet - anzeigen

       Bin auch in den Bug gelaufen.

      Der Bug tritt bei der Mac-App 3.10.11 auf bei einer lokalen Datenbank. Wen gewünscht kann ich auch mal auf on premise Linux testen.

      Grüße Maurice

      • Customer Support Ninox
      • uwe_groegor
      • vor 3 Monaten
      • Gemeldet - anzeigen

       Ich werde den Bug nochmals bei den Entwicklern ansprechen, damit er angegangen wird.

    • Michael.3
    • vor 10 Monaten
    • Gemeldet - anzeigen

    Bei mir tritt dieser Fehler bei der Mac-App-Version auf. Keine Cloud, sondern lokale Installation neuestes Release.

     

    Ein Fix wäre sehr wünschenswert!

    • Olli.1
    • vor 2 Monaten
    • Gemeldet - anzeigen

    Ich habe ebenfalls die Mac-App (3.11.4) ohne Cloud, nur Lokal.
    Mein Kalender wird mit dem Apple Kalender syncronisiert. Mittlerweile habe ich soviele " 01.01.1970 ", das mein iCloud-Kalender vollgelaufen ist und ich fehlermeldungen von Apple erhalte.

    Im Ninox Kalender kann man sagen, das nur 1 Monat retour syncronisiert werden soll. Allerdings werden trotzdem alle vorherig leere Datumsfelder mit 01.01.1970 in den Apple-Kalender syncronisiert. (am 01.01.1970 habe ich somit immer eine vierstellige Anzahl von Kalendereinträgen)

    Weil es scheint, dass das Ninox-Team diesen Fehler nicht gefixt bekommt, möchte ich nun die syncronisation mit dem Apple-Kalender löschen. Wie bewerkstellige ich dies direkt im Ninox-Kalender?

    Nehme ich im Apple-Kalender (auf allen Geräten und in der Cloud) den Ninox-Kalender raus, wird er nach jedem Neustart von Ninox wieder in den Apple-Kalender eingetragen und das Problem ist wieder da.

      • mirko3
      • vor 2 Monaten
      • Gemeldet - anzeigen

       Ich nutze diese Synchronisation nicht, aber in den Systemeinstellungen->Datenschutz&Sicherheit->Kalender kannst Du Ninox untersagen den Kalender zu benutzen. Vielleicht hilft Dir das. Mirko

    • Axel_Petrak.1
    • vor 2 Monaten
    • Gemeldet - anzeigen

    Es ist eine Frechheit vom Support hier keine Fix endlich bereitzustellen. Das Problem gibt es über ein Jahr !!!  Die Kosten haben sich für mich verfünffacht und der Support ist nicht einen Stern wert ! 

      • Paul_J_Herberhold
      • vor 2 Monaten
      • Gemeldet - anzeigen

       verfünffacht? Das kann nicht sein. Der Support hat mir versichert, dass es nur eine kleine Anpassung der Preise im einstelligen Bereich gab. Seitdem gehe ich davon aus, dass ich mir die jährlichen zusatzkosten von über 700 €, die mir entstehen, wenn ich meine Datenbank wie bisher nutzen will, nur einbilde.

      • Axel_Petrak.1
      • vor 2 Monaten
      • Gemeldet - anzeigen

       

      es ist sogar mehr ! Mein „ Problem „ ist da meine DB 14 GB ist .. bedeutet 2 Lizenzen zu 20Euro / Monat x 7 = 140€ / Monat ! Vor der Preiserhöhung ( vor 2 Jahren ) haben wir 19.50€ / Monat bezahlt. Für mich ist das Modell nur Wucher , da jede DB die Eigenschaft hat größere zu werden. Arbeite nur noch lokal ….. bitte nicht falsch verstehen, ich bin ein Ninox Fan und benutzte Ninox über 6 Jahre ! Nur wer über die Größe der DB sein Geld verdienen will sollte dann ein Rechenzentrum betreiben. 

Content aside

  • vor 2 WochenZuletzt aktiv
  • 31Antworten
  • 431Ansichten
  • 13 Folge bereits