| Autor |
Beitrag |
Klabautermann
  
Beiträge: 6366
Erhaltene Danke: 60
Windows 7, Ubuntu
Delphi 7 Prof.
|
Verfasst: Do 14.06.12 11:46
Hallo,
ich habe gerade ein interessantes Problem, welches ich mir nicht erklären kann. Ich habe für eine Anwendung eine SQLite-Schnittstelle entwickelt. Diese basiert auf den SQLite4Delphi Komponenten. Da das tDataSet-Objekt in diesen nicht vollständig implementiert ist, insbesondere die Filter Funktionalität fehlt, kopiere ich ein von diesen Komponenten geliefertes tSLDatset jeweils in ein tClientDataset und arbeite mit diesem. Performance und Speicherverbrauch sind hierbei nicht problematisch.
Das ganze funktioniert bei mir vollig Problemlos, auf dem Rechner eines Kollegen, wird hingegen die folgende Fehlermeldung geliefert:
| Zitat: | | Operation bei geschlossener Datenmenge nicht ausführbar |
Leider steht auf dem Rechner, auf dem das Problem auftritt kein Debugger zur Verfügung, durch die Ausgabe von Debugmeldungen konnte ich aber die den Fehler verursachende Zeile ausfindig machen:
  Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
| procedure CopyDataSet(aSource, aDest : tDataSet);
var
i : Integer;
BM : tBookmark;
begin
if not aSource.Active then
aSource.Open;
aSource.DisableControls;
BM := aSource.GetBookmark;
aDest.DisableControls;
try
aDest.Close;
aDest.FieldDefs.Clear;
for i := 0 to aSource.FieldDefs.Count - 1 do
begin
aDest.FieldDefs.Add(aSource.FieldDefs.Items[i].Name, aSource.FieldDefs.Items[i].DataType, aSource.FieldDefs.Items[i].Size, aSource.FieldDefs.Items[i].Required);
end;
if (aDest is tClientDataSet) then
(aDest as tClientDataset).CreateDataSet;
|
Das dieser Fehler an dieser Stelle auftritt, finde ich ausgesprochen verwirrend, denn das CreateDataSet muss meines Wissens immer bei geschlossener Datenmenge erfolgen, alles andere macht auch keinen Sinn. Auch habe ich versuchsweise mal die Tabelle aDest, vor den Aufruf geöffnet, was aber auch zu keinen Erfolg führte.
Kann mir bitte jemand erklären, wie es zu diesem Problem auf einigen Systemen kommt und wie ich es umgehe?
Gruß
Klabautermann
|
|
zuma
Beiträge: 660
Erhaltene Danke: 21
Win XP, Win7, Win 8
D7 Enterprise, Delphi XE, Interbase (5 - XE)
|
Verfasst: Do 14.06.12 12:18
ist auch sicher, das etwas in asource drin steht ? wenn er nicht die Fieldcount-Schleife durchläuft, kann er das dataset nicht createn.
Ich habe ebenfalls eine Methode, mit der ich Dataset's kopiere (in der Regel, um Query's in Clientdatasets zu wandeln, optional mit gleichzeitigem rüberschaufeln der Daten), allerdings nutze ich nicht die Fielddefs, sondern direkt die Fields bzw. deren Eigenschaften und kann ggf. noch eine Stringlist mitgeben für Felder, die im Ziel sein sollen, aber in der Quelle nicht enthalten sind.
Das nutze ich seit Jahren, der von dir genannte Fehler tritt bei mir nur dann auf, wenn mein Quell-Dataset leer ist (und ich das nicht abgefangen hab).
Ich vermute deinen Fehler also eher in der Quell-Datenmenge.
Moderiert von  Narses: Überflüssige Zeilenumbrüche/Leerzeilen entfernt._________________ Ich habe nichts gegen Fremde. Aber diese Fremden sind nicht von hier! (Methusalix)
Warum sich Sorgen ums Leben machen? Keiner überlebts!
Für diesen Beitrag haben gedankt: Klabautermann
|
|
Klabautermann 
Beiträge: 6366
Erhaltene Danke: 60
Windows 7, Ubuntu
Delphi 7 Prof.
|
Verfasst: Fr 15.06.12 12:44
Hallo,
ich habe eine den Quelltext mal dahingehend erweitert, dass er überprüft ob FieldDefs vorhanden sind, sowohl im Quell Dataset als auch noch einmal im Zieldataset bevor CreateDataSet aufgerufen wird. Nach seinen Tests konnte mir der entsprechende Kollege leider keine Entwarnung geben. Der Fehler bleibt bestehen.
Die Sache ist, dass der Kollege im Grunde mit einer Kopie meines Ausgabeordners arbeitet. Es nutzt also die gleiche EXE, die gleichen DLLs (inklusive der gleichen SQLite.DLL) und auch die gleiche Datenbank wie ich. Dennoch tritt der Fehler bei mir nicht auf, bei ihm hingegen schon. Ich verstehe nicht, wieso es auf seinen System zu diesem Fehler kommt bei mir aber nicht.
Gruß
Klabautermann
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Fr 15.06.12 12:47
Wenn Du von Deinem Entwicklungsrechner auf den Rechner des Kollegen per Netzwerk zugreifen kannst, würde ich nicht lange fackeln und den Remotedebugger anwerfen. Die Anwendung wird auf dem PC Deines Kollegen ausgeführt und Du kannst auf Deinem PC Haltepunkte setzen, durchsteppen, etc.
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
Für diesen Beitrag haben gedankt: Klabautermann
|
|
zuma
Beiträge: 660
Erhaltene Danke: 21
Win XP, Win7, Win 8
D7 Enterprise, Delphi XE, Interbase (5 - XE)
|
Verfasst: Fr 15.06.12 12:59
Eine Idee wäre noch:
gibt es evtl. Probleme mit Berechtigungen ?
Wir nutzen z.b. in der DB User, die Programme melden sich als best. User an.
Wenn nun ein Programm als User2 zugreift, aber nur Grant's für User1 vergeben sind,
ist klar, woran's liegt  _________________ Ich habe nichts gegen Fremde. Aber diese Fremden sind nicht von hier! (Methusalix)
Warum sich Sorgen ums Leben machen? Keiner überlebts!
Für diesen Beitrag haben gedankt: Klabautermann
|
|
Klabautermann
Beiträge: 6366
Erhaltene Danke: 60
Windows 7, Ubuntu
Delphi 7 Prof.
|
Verfasst: Fr 15.06.12 13:24
Hallo,
Nersgatt hat folgendes geschrieben  : | | Wenn Du von Deinem Entwicklungsrechner auf den Rechner des Kollegen per Netzwerk zugreifen kannst, würde ich nicht lange fackeln und den Remotedebugger anwerfen. Die Anwendung wird auf dem PC Deines Kollegen ausgeführt und Du kannst auf Deinem PC Haltepunkte setzen, durchsteppen, etc. |
gute Idee, mit dem habe ich zwar noch nie gearbeitet, aber das sollte hin zu kriegen sein. Zumindest technisch, Terminlich habe ich da größere zweifel, heute ist der Kollege zumindest schon wieder ausgebucht (nicht jeder darf sich wie wir Entwickler ständig in seinem Büro aufhalten ). Das werde ich bei nächster Gelegenheit mal in Angriff nehmen.
| zuma hat folgendes geschrieben : | Eine Idee wäre noch:
gibt es evtl. Probleme mit Berechtigungen ?
Wir nutzen z.b. in der DB User, die Programme melden sich als best. User an.
Wenn nun ein Programm als User2 zugreift, aber nur Grant's für User1 vergeben sind,
ist klar, woran's liegt |
Das ist auszuschließen, da SQLite schlichtweg keine Berechtigungen kennt. Das ist ein ziemlich primitives System in dem es heißt alles oder nichts, auch sonst ist es recht eigenwillig (z.B. wird für jede Tabelle ein Autoinc-Key angelegt, wenn du ihn nicht selbst schon einen in deiner Tabellendefinition hast) weil es alles so simpel wie möglich halten will.
Mein erster Gedanke war auch, dass etwas mit den Datei-Zugriffsrechten nicht stimmt. Das ist aber alles überprüft. Auch klappt der Datenbankzugriff als solcher Problemlos, immer wenn die die CopyDataSet Funktion nicht nutze kommen die Daten an (Das ganze läuft in einem " Exe <-> Scriptsprache <-> DB-Schnitstelle aus DLL" Kontext, wobei die DLL, sowohl eine Methode kennt um die Daten gleich in einem Script sprachen Konstrukt zu liefern, welches dann aber keine komfortable Navigation/Filterung in der Datenmenge mehr erlaubt, als auch eine um ein tDataSet ähnliches (ReadOnly) Objekt zu erhalten. Der erste Fall klappt, der zweite nicht).
Danke für eure Ideen,
Klabautermann
|
|
|
