Stand 22.02.2001

Object.GetRecordset (strSQL As String [, Optional strDBPassWord As String] )

Rückgabewert : ADO-Recordset

Beispiel1, Beispiel2 

Die GetRecordset-Funktion des FlowFact.Application Objektes

• dient dazu ein ADO-Recordset aus einer SQL Anweisung zu erzeugen;
  
• greift auf die FlowFact - Datenbank zu, ohne das weitere Verbindungsangaben nötig sind und bezieht sich dabei auf den in der FlowFact-Anwendung angemeldete Benutzer;
  
• verwendet die Zugriffsberechtigungen auf Datensatzebene, mit denen FlowFact arbeitet und gibt nur Daten zurück, für die mindestens Leseberechtigung besteht.

Um diese Datensicherheit zu realisieren wird auf zwei Ebenen gearbeitet:

Aus der SQL Abfrage wird die Haupttabelle ermittelt. Aus dieser werden nur die Datensätze zurückgegeben, für die Leseberechtigung besteht (wenn in der Tabelle das Feld für Berechtigungen, "ACL", enthalten ist ) - ansonsten alle DS die der SQL-Abfrage entsprechen;

Bei Abfragen, die auf mehrere verknüpfte Tabellen zugreifen, wird für jeden Datensatz einer verknüpften Tabelle geprüft, ob der Benutzer das Recht hat, diesen zu lesen (wiederum nur wenn in der Tabelle das Feld für Berechtigungen, "ACL", enthalten ist). Wenn keine Leseberechtigung vorhanden ist, werden die Daten mit "-keine Leseberechtigung-" überschrieben oder mit einem dem Datentyp entsprechenden Nullwert gefüllt. Ausgenommen davon sind die Felder ACL, Kennung und alle GUID-Felder. 

Achtung:
Bei einer Abfrage die zwei oder mehr Tabellen mit ACL-Feldern einschießt, wird aus Gründen der Datensicherheit ein 'künstliches' Recordset erzeugt, dessen Feldnamen aus "Tabellenname.Spaltenname"  (z.B. "AD.name" ) bestehen. In diesem Recordset befinden sich alle Datensätze im Status "neu angelegt"! U.U. kann dies zu ungewollten Nebeneffekten bei der Bindung an Daten-Steuerelemente führen. Da aber ein solches Recordset nicht zum Speichern/Änderen von Daten über UpdateRecordset verwendet werden kann, spielt dies für die SQLServer-Datenbank keine Rolle!!

Damit obengenannter Sicherheitsmechanismus arbeiten kann, werden nur SQL-Abfragen akzeptiert, die nach-folgenden Einschränkungen unterliegen :

Als Haupttabelle gilt der erste Tabellennamen nach "FROM". Hierbei sind überflüssige Leerzeichen zu vermeiden. Auch die Syntax "Schemaname.Tabellenname" wird abgelehnt.

Beispiele für eine gültige Abfrage:

Select * from AKT inner join Aktivitätenarten on AKT.ART_DSN = Aktivitätenarten.dsn

Folgende Abfragen wären aber ungültig:

Select * from dbo.akt inner join aktivitätenarten on akt.art_dsn = aktivitätenarten.dsn

Für die zweite Ebene gilt, das bei den verknüpften Tabellen die Spalten ACL und NEU_BEN_DSN in der Abfrage enthalten sein müssen (natürlich nur, wenn sie in der Tabelle vorhanden sind). Dies kann durch die Verwendung in der Spaltenliste geschehen oder durch den Spaltenplatzhalter "*".

Beispiel

Select * from akt inner join ad on aktad_dsn = ad.dsn

- oder -

Select akt.datum, akt.notiz, ad.kennung,ad.firma, ad.name, ad.ACL, ad.NEU_BEN_DSN from akt inner join ad on akt.ad_dsn = ad.dsn

Abgelehnt werden SQL- Abfragen, die:

• GROUP BY, UNION, COMPUTE etc. enthalten. Nach der WHERE-Klausel wird nur die ORDER BY - Klausel akzeptiert.,
• Spaltenfunktionen enthalten, wie CAST, SUBSTRING, etc.

Bei den Tabellen:
AKTDET, AKTENDET, ANFDET, DETAILSDET, OBJDET, PROJEKTEDET, VERTRÄGEDET
hängt die Lese-Berechtigung vom jeweiligen DS der Primär-Tabelle ab. Deswegen werden Abfragen mit diesen Tabellen nur zugelassen, wenn sie in direkter Verbindung mit Ihrer Primärtabelle verwendet werden

Bsp.:

Select obj.kennung, objdet.eingabe from obj inner join objdet on obj.dsn = objdet.obj_dsn

(auf Leerstellen achten !)

Hinweis : Wenn das Recordset zum Updaten der ...DET-Tabelle weiterverwendet werden soll, dann dürfen nur Spalten aus dieser einen Tabelle in der Abfrage verwendet werden.

z.B."Select objdet.* from obj inner join objdet on obj.dsn = objdet.obj_dsn"

Aus ähnlichem Grund ist bei der Tabelle ARCHIV ist nur SELECT * FROM ARCHIV (WHERE ...) möglich. Diese Abfrage ist dann auch zum Updaten verwendbar. Der ursprünglichen SQL eine (weitere) WHERE-Klausel hinzugefügt, in der die Abhängigkeit zur Leseberechtigung der zugehörigen Aktivitäten sichergestellt wird.

z.B.

SELECT * FROM ARCHIV WHERE ..Ltrim(Kennung) = 7 AND ( Archiv.DSN in ( SELECT ARCHIV.DSN FROM ARCHIV LEFT JOIN AKT ON ARCHIV.AKT_DSN = AKT.DSN WHERE ((AKT.ACL is Null or AKT.acl like '%G{1}R%' or AKT.acl like '%U{56C036E1-72AA-11D4-8FE5-0050041BE62B}%' ))) )

Die Tabelle BLOB : diese kann nicht über GetRecordset gelesen werden (Datenmenge & Sicherheit!). Hier können Informationen über die Funktionen des Application.BLOB -Objektes ermittelt werden (z.b. GetBlobInfo).

Weitere Änderungen/ Neuerungen :

• Optional kann das Datenbankpasswort des SQL Servers mit übergeben werden. In diesem Falle werden alle Abfragen wie im QueryAnalyzer zurückgegeben. Die zuvor genannten Einschränkungen bzgl. Abfragen und Tabellen gelten dann nicht!
  
• bei Abfragen, die zwei oder mehr Tabellen mit DS-Leseberechtigungen (ACL-Feldern) verwenden, wird ein Recordset erzeugt, dessen Feldnamen aus "Tabellenname.Spaltenname" besteht (siehe oben). Bisherige Zugriffe auf Felder über den Namen müssen dann evtl. angepasst werden. Dadurch werden Überschneidungen bei gleichlautenden Spalten aus verschiedenen Tabellen oder bei mehrfacher Auflistung einer Spalte vermieden.
  
• einfache Aggregatsfunktionen (COUNT, SUM, MAX, MIN, AVG, VARP, STDEV , STDEVP) sind jetzt möglich, wobei sich diese Spaltenaggregationen immer auf die Datensätze beziehen, auf die Leseberechtigung besteht (und natürlich alle Einschränkungen der WHERE Klausel). Achten Sie hier auch auf die Leerzeichen!
  
• selbstdefinierte X - Tabellen unterliegen nicht der Berechtigungsverwaltung, dürfen aber auch  kein 'ACL' oder 'NEU_BEN_DSN' Feld enthalten

 

 

Stand 22.02.2001

UpdateRecordset (rsToUpdate As RecordSet [, Optional strDBPassWord As String])

Rückgabewert : keiner

Beispiel1, Beispiel2

Bei Verwendung in VBScript muss dass Recordset eingeklammert werden, da die Variable nicht als Recordset deklariert werden kann, aber 'By Reference' an  Application.Updaterecordset übergeben werden muss:
Application.UpdateRecordset (rsAdresse) [, strDBPassWord]   (siehe Bsp. 2)

In VB hat der Aufruf hingegen folgende Form:
oFFApp.UpdateRecordset rsAdresse [, strDBPassWord]  (siehe Bsp. 1)

Einschränkungen für Recordset:

Allg.:

• Es dürfen in dem Recordset, das geupdatet werden soll nur die Spalten einer Tabelle eingebunden sein, am besten mit "SELECT Tabellenname.* FROM .... einschränken, wenn mit Join Tabellen in der Abfrage verbunden werden, oder (noch besser) ein zweites Recordset verwenden!
  
• Bei fehlender Berechtigung werden Änderungen/Löschungen stillschweigend rückgängig gemacht.
  
• Bei den Tabellen AKTDET, AKTENDET, ANFDET, DetailsDet, OBJDet, ProjekteDet, VerträgeDet werden automatisch die Rechte des Parent-DS kontrolliert
  
• Entsprechend bei ARCHIV, hier wird die Berechtigung des AKT-DS verwendet, wenn der Archiv-DS mit einer Aktivität verbunden ist.

Bei den Tabellen wird unterschieden nach

ABRECHNUNG, AD, ADMKM, AKT, AKTDET, AKTMKM, AKTEN, AKTENDET, AKTENMKM, ANF, ANFDET, ANFMKM, ARCHIV, BIBLIOTHEK, DETAILS, DETAILSDET, DETAILSMKM, OBJ, OBJANF, OBJDET, OBJMKM, PROJEKTE, PROJEKTEDET, PROJEKTEMKM, VERTRÄGE, VERTRÄGEDET, VERTRÄGEMKM

Abrechnungssparten, Abrechnungstypen, Aktivitätenarten, AktivitätenStatus, Fldart, Fldartopt, Gruppen, MKM, EMSK, BEN

Hinweis: unter diese fällt auch die Tabelle BLOB. Hier sollten Änderungen nur über die Funktionen des Application.BLOB -Objektes durchgeführt werden.

Die nachfolgenden Felder sind immer mit dem angemeldeten FlowFact-Benutzer gekoppelt, und werden automatisch gefüllt / bzw. Änderungen werden rückgängig gemacht.

Daher müssen bei Tabellen, welche diese Felder (s.u.) enthalten, diese im Recordset eingebunden sein:

NEU_BEN_DSN, ÄN_BEN_DSN, TOUCH, ANGELEGT

Wenn bei diesen Felder aber eine andere Benutzer-DSN oder ein anderes Datum eingetragen werden muss, dann kann dies mit dem Aufruf mit dem Datenbank-Administrator Kennwort erfolgen

Beim Einfügen von Datensätzen kann die DSN selbst generiert werden (aus cUtil.newGUID) oder sie wird automatisch beim Insert generiert, wenn das Feld noch leer ist. Geändert werden sollte eine DSN aber nie! Für die Verknüpfungen wird keine Sicherheit zu Verfügung gestellt! Falsch verknüpfte Daten können u.U. nicht über die FlowFact - Anwendung wiedergefunden werden.

hier ist es entsprechend wie bei der DSN: wenn es noch leer ist, wird es automatisch gefüllt (über cDButil.mdb_make_kennung). Hier besteht daher die gleiche Funktionalität wie in FlowFact (bzgl. Präfixe und '#')

(da es nicht sinnvoll ist)

SUCHNAME, CONTROLLS, STATEMENT

An diesen kann nur bei Aufruf mit dem SQL-Server Passwort etwas geändert werden

AUTOTEXT, FAXAKT_ACL, IMMONET_GRUPPE, RECHTE_FENSTER, RECHTESCHABLONEN,

SCANAKT_ACL, SIGNATUR, strCalendarOptions (alle Felder vom Typ "text" aus BEN)

1. Aus dem Inhalt des Feldes Telefon werden, wenn hier Änderungen eingetragen wurden, die TAPI-Nummern erstellt (siehe dazu: Aufbau des Feldes Telefon)

2. IDX_FIRMA, IDX_NAME werden aus den Werten der Felder Firma und Name generiert, hier besteht auch die gleiche Funktionalität wie in FlowFact (bzgl. '#')

3. bei AD à Briefanrede wird aber nicht befüllt

Aus dem Wert des Feldes Eingabe werden automatisch die Von / Bis Werte erstellt 

weiteres:

Da dieses Recordset prozessübergreifend eingesetzt wird, werden gesetzte Recordset-Filter, Datensatzpositionen u.a. nicht berücksichtigt, verschieden Eigenschaft bleiben nicht erhalten und nicht alle Methoden können wie sonst ausgeführt werden (z.B. Requery).

Große Datenmengen können nicht auf einen Schlag geändert werden. Je größer der einzelne Datensatz um so weniger Datensätze können in einem Aufruf geändert werden! 

Damit zusammenhängend ergeben sich auch die Einschränkungen bzgl. dem Löschen von Daten:

Datensätze die mit 'Delete' oder über ein Daten-Controll gelöscht werden, sind im Recordset immer noch vorhanden, aber versteckt und zum Löschen markiert. Die UpdateRecordset-Methode stellt sicher, dass Detaildatensätze und Merkmale mitgelöscht werden, und der eigentliche, zum Löschen markierte DS wird, unabhängig von Recordset, in der Datenbank gelöscht. Im Recordset hingegen wird dieser Datensatz-Löschstatus zurückgesetzt und er bleibt erhalten. Daher müssen Sie, falls das Recordset noch weiter verwendet werden soll, dieses neu abfragen!

Verknüpfungen ( wie z.B. von Aktivitäten zu Adressen) werden unterbrochen!