4D sorgt dafür, dass Ihre Datensatzauswahl in Bezug auf die Löschung von Datensätzen konsistent bleibt

Das Löschen von Daten sollte mit Vorsicht gehandhabt werden. Um Probleme zu vermeiden, können wir Transaktionen verwenden oder uns auf Backups und Protokolle verlassen.

In 4D 20 R4 wurden einige Verbesserungen vorgenommen, um Ihre Datensatzauswahl stabil und konsistent im Hinblick auf das mögliche Löschen von Datensätzen in dieser Auswahl zu machen.

Lesen Sie weiter, um zu erfahren, wie Ihr 4D Code von Anfang an sicher sein wird.

4D internes Verhalten

Wie Sie vielleicht bereits wissen, verwaltet 4D intern eine Adresstabelle, die auf physische Datenblöcke auf der Festplatte verweist. Die Handhabung dieser Adresstabelle in der internen Architektur von 4D kann zu den hier beschriebenen Problemen führen, wenn eine Auswahl von Datensätzen bearbeitet wird.

Wenn ein Datensatz gelöscht wird, wird auch sein Verweis auf die physischen Daten in der Adresstabelle gelöscht.

Um Löcher zu vermeiden und die Nutzung des Speichers für die Adresstabelle zu optimieren, verwendet 4D beim Anlegen eines neuen Datensatzes wieder freie Plätze in dieser Adresstabelle.

Wenn Sie eine Auswahl von Datensätzen erstellt haben (z. B. mit einer Abfrage), kann ein Datensatz, der zu dieser Auswahl gehört, nach dem Löschen eines neuen Datensatzes über dieselbe vorherige Datensatznummer in der Adresstabelle referenziert werden.

So kann es vorkommen, dass Sie in Ihrer Auswahl Daten finden, die Sie gar nicht erwartet haben.

Ein konkretes Beispiel

Ein Mitarbeiter hat einen Stapel von Aufgaben zu bearbeiten. Bei der Erstellung wird die Aufgabe mit dem Status TO DO versehen.

In regelmäßigen Abständen wird dem Mitarbeiter eine E-Mail mit seinen TO DO-Aufgaben zugesandt. Es wird eine Auswahl dieser Aufgaben erstellt, und es gibt eine Schleife für jede Aufgabe, um die Details in der E-Mail bereitzustellen.

Der Administrator hat jedoch die Berechtigung, einige Aufgaben zu löschen. Wenn der Administrator versehentlich eine Aufgabe in der obigen Auswahl löscht und direkt danach eine neue Aufgabe für einen anderen Mitarbeiter erstellt wird … was passiert dann?

Vor 4D 20 R4

Die neu erstellte Aufgabe wurde in der Schleife gefunden, und da es sich um eine Aufgabe für einen anderen Mitarbeiter handelt, fällt sie nicht in den Geltungsbereich!

Nach 4D 20 R4

Die neu erstellte Aufgabe wird nicht in der Schleife gefunden und die Auswahl der Daten ist immer konsistent und Sie können sich darauf verlassen.

Der obige Anwendungsfall ist nicht so häufig, da wir meistens einen Status an einem Datensatz ändern, anstatt ihn direkt zu löschen.

Oder vielleicht haben Sie sich angewöhnt, die Kohärenz eines Datensatzes/einer Entität (in Bezug auf die Auswahlkriterien) noch einmal zu überprüfen, bevor Sie ihn/sie weiterverarbeiten.

Wie auch immer, Sie müssen sich darüber keine Gedanken mehr machen.

Lassen Sie uns dies in Aktion in 4D Code sehen

Im folgenden Beispiel erstellen wir die $target Entitätsauswahl.

Danach löschen wir eine Entität, die zu dieser Entitätsauswahl gehört (wir tun dies in demselben Codestück zum schnellen Verständnis, aber wir können uns vorstellen, dass dies von einem anderen Benutzer in einem anderen Prozess getan wird).

Die Schleife verarbeitet nur noch die beiden Entitäten (internalID 10 und 12).


var $target; $customers : cs.CustomersSelection
var $customer : cs.CustomersEntity
var $newCustomer : cs.CustomersEntity
var $status : Object

// Three customers are retrieved with internal ID 10, 11, 12
$target:=ds.Customers.query("internalID >= 10 and internalID <= 12")
ASSERT($target.length=3)

// We delete the customer with internalID = 11
$customers:=ds.Customers.query("internalID = :1"; 11).drop()

// We create a new customer with internalID = 99 
$newCustomer:=ds.Customers.new()
$newCustomer.internalID:=99
$status:=$newCustomer.save()

// We loop on the $target entity selection
// got before the creation of the new customer
For each ($customer; $target)
// The new customer is not in the entity selection ... 
ASSERT($customer.internalID#99)
End for each 

Wichtig: Diese Funktion gilt für Daten, die mit klassischen 4D Standard QUERY Befehlen und ORDA bearbeitet werden.

Arbeiten Sie weiterhin sicher mit 4D, denn Ihre bevorzugte Entwicklungsplattform nimmt Ihnen viele Aufgaben ab, damit Sie sich auf Ihre Geschäftslogik konzentrieren können!

 

 

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert ist seit 2017 als Product Owner im 4D Produktteam tätig. Als Product Owner ist sie für das Schreiben der User Stories und deren Umsetzung in funktionale Spezifikationen zuständig. Ihre Aufgabe ist es auch, sicherzustellen, dass die Implementierung der Funktionen den Anforderungen des Kunden entspricht. Marie-Sophie ist Absolventin der ESIGELEC Ingenieurschule und begann ihre Karriere als Ingenieurin bei IBM im Jahr 1995. Sie nahm an verschiedenen Projekten teil (Wartungs- oder Build-Projekte) und arbeitete als Cobol-Entwicklerin. Dann arbeitete sie als UML-Designerin und Java-Entwicklerin. In letzter Zeit bestand ihre Hauptaufgabe darin, funktionale Anforderungen zu analysieren und zu schreiben sowie Geschäfts- und Entwicklungsteams zu koordinieren.