data control error

derGugi

derGugi

Erfahrenes Mitglied
Hallo

Warum erscheint ein Error, wenn ich ein Recordset dem Data control zuweisen will? er sagt dann: function or interface marked as restricted, or the function uses an automation type not supported in Visual Basic. Ich benutze VB 5 Professional. Hier ein kleiner ausschnitt:
Code: 
Set rstBad = TempDB.OpenRecordset(stRealTabName & "_bad")
Set frmRepBadRecs.datBadRecs.Recordset = rstBad
ich mach es wie in der Hilfe, aber beim beim zweiten set erscheint immer der Fehler. Weiss jemand Rat?
 
Ich bin nicht ganz sicher, aber ist das DataControl-Steuerelement nicht eigentlich auf ADO basierend? Dein Recordset-Objekt ist jedenfalls DAO.
Versuch das mal, indem Du explizit angibst, dass Du ein ADO-Recordset benutzt.
 
nö, das ist schon dao. habs mal mit ado probiert, klappt aber ned.

das komische ist, das ich genau das beispiel aus der hilfe kopiert habe und es immer noch ned funzt...
 
Das ist echt komisch. Hast Du das vielleicht einfach mal ohne das Set davor versucht?
Ich hab hier gerade kein VB installiert, und schon gar nicht Version 5. Vielleicht liegt es auch daran... :rolleyes:
 
ohne set bringt er die errormeldung invalid use of property. Das mit der VB version dachte ich auch schon, aber kanns grad nicht ausprobieren, da ich keine neuere Version installiert habe. Aber es müsste ja gehen, da es die Hilfe von VB 5 ist...

btw: du magst kein visual basic, bist aber mod hier?? widerspricht sich das nicht etwas? :)
 
Zuletzt bearbeitet:
Code: 
Dim rs As DAO.Recordset
' ...
Set Data1.Recordset = rs
Der Code scheint unter VB6 anstandslos zu funktionieren. Ich hab das zwar nur mal kurz getestet, aber der Compiler gibt keinen einzigen Fehler aus.
Ich bin einfach mal davon ausgegangen, dass Du mit DataControl das ganz normale Standard-Steuerelement namens "Data" meinst.

du magst kein visual basic, bist aber mod hier?? widerspricht sich das nicht etwas?
Zum Vergrößern anklicken....
Klar tut es das. :)
 
Hassen ist wohl nicht der richtige Ausdruck... :rolleyes:
Ich halte VB nur einfach nicht für eine wirklich logische Programmiersprache und die Umgebung ist auch teilweise schlimm. Ständig mischt sich der Compiler in meinen Code ein. Die sogenannte Objektorientierung bis VB 6 ist auch lachhaft... Es gibt keine Pointer, keine direkten Speicherzugriffe. Wahrscheinlich ist das genau das, was Microsoft mit einer "sicheren" Programmiersprache meinte.
Das was nach dem Compilieren aus dem Code gemacht wird, ist auch weit entfernt von irgendwelchem richtigen Maschinencode.
Delphi, C++ und C# find ich da schon viel logischer und effektiver.

So... genug gelästert. ;)
 
jo hast schon recht. aber wenn man zeiger und so möchte dann nimmt man halt delphi und muss sich gar nicht erst mit vb rumschlagen :)
 
Naja, so oft braucht man Pointer ja nicht unbedingt. Aber wenn man dann mittendrin doch mal in die Situation kommt, wo man Pointer braucht, hat man ein Problem.
Da kann es dann nur von Vorteil sein, wenn man sich mit Delphi oder C++ mal schnell eine DLL zusammenschraubt, die genau das macht, was VB nicht kann. Und die bindet man dann im VB-Code ein. :)

Aber trotzdem muss man bei VB irgendwie jeden Scheiss über API-Funktionen machen und überall Verweise setzen. Bei Delphi gibt es dafür schon fertige Klassen oder man nimmt sich eine Komponente aufs Formular und der Verweis wird automatisch gesetzt. Dazu kommt halt noch die Tatsache, dass die Steuerelemente der VCL bequem im Formular ausgerichtet werden können. Mit VB muss man das alles selber im Code festlegen - und dann auch noch mit Twips als Masseinheit... :rolleyes:
Und das was man mit VB als Verweis festlegt, muss man später auch noch zur Laufzeit mitliefern. Dadurch wird die schöne kleine VB-Anwendung mit 60kb mal schnell um 3MB grösser. :eek:

Eigentlich ist das schon ziemlich genial, wie sich Microsoft mittlerweile schon seit fast zehn Jahren immer an einer richtigen objektorientierten Sprache vorbeimogelt und sie trotzdem verkauft, obwohl die Hälfte noch fehlt. :]
Aber jetzt, wo die Entwickler von VB.net ziemlich stark von Delphi abgeguckt haben, gibt es ja immerhin einen weiteren Schritt in Richtung OOP. Ehrlich gesagt, hab ich von VB.net noch nicht wirklich viel gesehen - aber ich kann mir auch nicht richtig vorstellen, dass es mittlerweile eine logische Methode gibt, mit der man Klassen ableiten kann.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück