DevHB

Ups, zu schnell gelesen: ' Modul Private Const MAX_COMPUTERNAME_LENGTH = 15 Public Declare Function GetComputerNameAPI Lib "kernel32" Alias "GetComputerNameA" ( _ ByVal lpBuffer As String, _ nSize As Long _ ) As Long Public Function GetComputerName( _ ) As String Dim sBuffer As String, _ sName As String Dim lResult As Long, _ l As Long l = MAX_COMPUTERNAME_LENGTH + 1 sBuffer = VBA.Space$(l) lResult = GetComputerNameAPI(sBuffer, l) If (lResult = 1) Then sName = VBA.Left$(sBuffer, VBA.InStr(1, sBuffer, VBA.Chr$(0)) - 1) GetComputerName = sName Exit Function End If GetComputerName = VBA.Constants.vbNullString End Function Die Windowsversion kannst Du mit diesem Tip auslesen: http://www.activevb.de/tipps/vb6tipps/tipp0129.html

Hi, den Rechnernamen gibts per API: ' in ein Modul Public Declare Function GetUserNameAPI Lib "advapi32.dll" Alias "GetUserNameA" _ (ByVal lpBuffer As String, _ nSize As Long _ ) As Long Public Function GetUserName( _ ) As String Dim sBuffer As String, _ sUser As String Dim lBuffer As Long, _ lRet As Long lBuffer = 255 sUser = VBA.Space$(lBuffer) lRet = GetUserNameAPI(sUser, lBuffer) If (lRet <> 0) Then GetUserName = VBA.Left$(sUser, lBuffer - 1) Exit Function End If GetUserName = VBA.Constants.vbNullString End Function 'Aufruf: Private Sub Form_Load Call MsgBox(GetUserName) End Sub

Die Funktionen sind VB intern und können überall implementiert werden. Das kann so in die Form etc... Kannst ja im Form_Load die Überprüfung machen, also Reg-Werte auslesen, überprüfen und ggf. abbrechen.

Hi, so kannst Du in die Reg schreiben: ' speichern Call VBA.SaveSetting("DeinAnwendungsname", "DeineSection", "DeinKey", "SettingValue") Dim sValue As String ' lesen sValue = VBA.GetSetting("DeinAnwendungsname", "DeineSection", "DeinKey", "Default") ' löschen Call VBA.DeleteSetting("DeinAnwendungsname", "DeineSection", "DeinKey") Das landet dann alles in "HKEY_CURRENT_USER\Software\VB and VBA Program Settings\XXX". Wobei XXX dann natürlich Dein Anwendungsname ist.

Hi, da musst Du selber Hand anlegen, d.h. z.B. mit dem VB - internen den Treeview drucken. - TreeView durchlaufen - Daten in String - Übergabe an Printer Object - Ausdrucken über das Printer object

Ahh, ich VollIdiot... Also der Aufruf der Form "frmKFZ_Neu" muss geändert werden: Private Sub cmdKFZ_Neu_Click() With frmKFU_Neu ' rs übergeben Set .KFZ = rsKFZ ' form anzeigen Call .Show End With ' Call Load(frmKFZ_Neu) '- rsKFZ an USerofm frmKFZ_Neu.KFZ übergeben ' Set frmKFZ_Neu.KFZ = rsKFZ ' Call frmKFZ_Neu.Show End Sub Grund: Bei "Load(FormNAme)" wird das "Form_Load" Event von frmKFZ_Neu aufgerufen, der Code abgearbeitet, in dem er das Recordset braucht, es jedoch erst vor dem "Show" gesetzt wird! Und geht nu?

ah, noch einen Fehler gefunden, zumindest im Post, hast Du den auch im Code? Option Explicit ' >>>dies ist fehlerhaft : Private WithEvents rsKFZ As ADODB.Recordset so ist es richtig: Private WithEvents mrsKFZ As ADODB.Recordset ---------------------------------------------------------------------- Public Property Set KFZ(ByRef rs As ADODB.Recordset) Set mrsKFZ = rs End Property ---------------------------------------------------------------------- Public Property Get KFZ() As ADODB.Recordset [B]falsch: Set rsKFZ = mrsKFZ muss [/b] Set KFZ = mrsKFZ End Property ---------------------------------------------------------------------- Private Sub Form_Load() '- Springe zum ersten Datensatz rsKFZ.MoveFirst While Not rsKFZ.EOF Me.cboGastype_Value.AddItem (rsKFZ.Fields("F_Description")) rsKFZ.MoveNext Wend End Sub

Hi, ja, Du musst es umbennnen. Mach mal im Form_Load eine Überprüfung, ob das Recordset gültig ist: If (Not (mrsKFZ Is Nothing)) Then '- Springe zum ersten Datensatz mrsKFZ.MoveFirst While Not mrsKFZ.EOF Me.cboGastype_Value.AddItem (mrsKFZ.Fields("F_Description")) mrsKFZ.MoveNext Wend Else MsgBox "Recordset ist Nothing" End If

Naja, Rs brauchst Du, weil so die Synthax für Properties ist. Rs ist der neue Wert, der der property/membervariablen zugewiesen werden soll. Funktionieren tut das Ganze wahrscheinlich nicht, da Option Explicit ' [B][B]>>>[/B]dies ist fehlerhaft : [/B]Private WithEvents rsKFZ As ADODB.Recordset [B]so ist es richtig:[/B] Private WithEvents mrsKFZ As ADODB.Recordset ---------------------------------------------------------------------- Public Property Set KFZ(ByRef rs As ADODB.Recordset) Set [B]m[/B]rsKFZ = rs End Property ---------------------------------------------------------------------- Public Property Get KFZ() As ADODB.Recordset Set rsKFZ = [B]m[/B]rsKFZ End Property ---------------------------------------------------------------------- Private Sub Form_Load() '- Springe zum ersten Datensatz rsKFZ.MoveFirst While Not rsKFZ.EOF Me.cboGastype_Value.AddItem (rsKFZ.Fields("F_Description")) rsKFZ.MoveNext Wend End Sub[B][/B] Du in den Properties eine andere Variable zuweist (beachte in den Properties das m und Deine Deklaration des Recordsets auf "frmKFZ_Neu".

Hi, Option Explicit [b]>>>> Anfang Bereich A <<<< [/b] ------------------------------------------------------ Public WithEvents rsKFZ As ADODB.Recordset [b]>>>> Ende Bereich A <<<<[/b] ------------------------------------------------------ [b]>>>> Anfang Bereich B <<<< [/b] Public Property Set KFZ(ByRef rs As ADODB.Recordset) Set mrsKFZ = rs End Property ------------------------------------------------------ Public Property Get KFZ() As ADODB.Recordset Set rsKFZ = mrsKFZ End Property ------------------------------------------------------ Hierbei werden zwei versch. Varianten gemischt. Ich habe im Code mal 2 Bereiche markiert: A und B. Bereich A ist der Formweite Deklarationsteil. Alles was hier deklariert ist (private, dim) ist innerhalb der Form, aber nicht nach außen sichtbar (andere Formen etc...). Wird hier etwas Public deklariert, ist es nach außen sichtbar. Wenn Du nun das Recordset "Public" in Bereich A deklarierst, dann brächtest Du die beiden Properties nicht, da die ja nur für den Zugriff auf private Elemente eines Objektes (in diesem Fall die Form) zuständig sind. Aber, das wollen wir ja nicht, da wir ja möglichst Privat programmieren wollen... Also ändern wir Public WithEvents m_rsKFZ As ADODB.Recordset in Private WithEvents m_rsKFZ As ADODB.Recordset Ich habe mir zusätzlich angewöhnt, bei Deklarationen für Properties ein "m_" oder "m" vor die Variable zu hängen, dann sehe ich, welche für Properties und welche zum "normalen" Arbeiten zuständig sind. Ich würde Dir empfehlen, immer genau zu überlegen, in wie weit ein Objekt oder eine Variable im Projekt sichtbar sein soll, denn hier Public WithEvents rsKFZ As ADODB.Recordset ------------------------------------------------------ Private Sub cmdKFZ_Neu_Click() Call Load(frmKFZ_Neu) Set frmKFZ_Neu.KFZ = rsKFZ Call frmKFZ_Neu.Show End Sub ist rsKFZ wieder als Public deklariert, brauchst Du den denn öffentlich, wenn Du ihn per Property übergibts? Ich denke nicht, denn ansonsten könntest Du ja auch einfach von der Form "frmKFZ_NEU" darauf zugreifen: ' frmKFZ_NEU: Private Sub Form_Load frmMain.rsKFZ.Open (...) End Sub ABER, auch dass wollen wir nicht, da wir möglichst privat und OO-Programmieren wollen... Ich hoffe ich konnte Dir helfen...

Moin, da hast Du zwei Möglichkeiten: 1.) die MSXML DOM Lib - Vorteil: Du kannst fast wie mit einer DB mit der XML-Datei arbeiten, d.h. Suchmöglichkeiten, Insert oder AppendChild. Nachteil: MSXML.dll muss ausgeliefert werden 2.) die Datei per Hand erstellen - Vorteil: keine Dll mitliefern, eventuell schneller Zu 1.) schau Dir mal dieses kleine Tutorial an, das ist zwar fürs lesen, jedoch siehst Du da schon, wie man mit der Lib umgeht. http://www.activevb.de/tutorials/tut_msxml/msxml.html Zu 2.) Du baust die XML - Datei in einem String auf und speicherst den einfach in eine Datei mit der Endung xml.

schönen feierabend...

Jein. Ich handhabe das so, dass ich so privat wie möglich programmiere, d.h. ich übergebe selten Recordsets an andere Formen (auch daher, dass ich Änderungen nur über die Connection bzw. eine Klasse löse). Was Du machen könntest, wäre ein Modul (z.B. modWorkingRecordsets), in denen Du öffentliche Funktionen mit Rückgabewert ADODB.Recordset erstellst. Dann musst Du nur noch die Funktion aufrufen: 'Modul "modWorkingRecordsets" Public Function GetKFZ_Rs( _ ) As ADODB.Recordset Dim Rs As ADODB.Recordset Set Rs = New ADODB.Recordset Call Rs.Open ("T_KFZ", modVerbindung.gConnection, adOpenDynamic, adLockPessimistic) If (Not (Rs Is Nothing)) Then Set GetKFZ_Rs = Rs End If End Function ' aufruf in Form Private m_Recordset As ADODB.Recordset Private Sub Form_Load Set m_Recordset = modWorkingRecordsets.GetKFZ_Rs ' und mit m_Recordset weiterarbeiten End Sub Ich würde mir überlegen, ob es wirklich Sinn macht, wenn Du die Recordsets an Formen übergibts, denn eigentlich brauchst Du die bei Dir ja nur, um Änderungen zu machen. Wenn Du dass mit der Connection (die Du ja eh schon global zur Verfügung hast) machen würdest, würde der ganze Kram wegfallen. (wieder ein Punkt, dem Du Deinem Ausbilder sagen kannst, warum (zumindest in Deinem Fall) die Aktualisierung per Recordset Müll ist ) Zudem muss Du beachten, JEDES Recordset hat nach dem Öffnen eine aktive Connection. Die würde sich mit "Set Rs.ActiveConnection = Nothing" lösen lassen, ist aber auch irgendwie unsauber.

ausführlicher wäre die Schreibweise wenn "modVerbindung.gConnection". Das zweite hat nicht funktioniert, da die Open-Methode des ADODB.Recordsets als 2. Parameter eine aktive Connection benötigt (ADODB.Connection), die Funktion "ConnectionOpen" aber einen Boolean zurückgibt.

So langsam erschleicht mich die Ahnung, das Du teilweise überhaupt nicht weißt, was Du machst, kopierst Du den Code ohne ihn versuchen zu verstehen? Hast Du Dir die Funktion "ConnectionOpen" mal angeschaut und versucht diese nachzuvollziehen? Jetzt würde ich gerne von Dir wissen, warum das so funktioniert und nicht anders?

Naja, das ist wurscht. Ich verwende immer die lange schreibweise, in Deinem Fall "Verbindung.Connection". An dem Beispiel siehst Du auch, dass es wesentlich besser ist, den Variablennamen und Modulnamen Vorschübe zu geben, damit man sich im Quelltext besser zurecht findet. In Deinem Fall: "Verbindung" wird zu "modVerbindung", da es anscheinend ein Modul ist. "Connection" solltest Du ja umbennen, z.B. in "g_Connection", damit es sich von der "ADODB.Connection" differenziert. Wenn Du jetzt noch die gepostete Funktion verwendest, kannst Du über If (modVerbindung.ConnectionOpen(g_Connection)) Then ' verbindung besteht Else ' verbindung ist geschlossen, nothing oder fehler End If

Hi, nimm am Besten eine Funktion zum Öffnen der DB: 'Connection zur DB Public Function ConnectionOpen(Cn As ADODB.Connection) As Boolean Dim Msg As String 'Object generieren If Cn Is Nothing Then Set Cn = New ADODB.Connection End If With Cn If Cn.State = adStateOpen Then ConnectionOpen = True Exit Function End If 'Beschreibung Connection On Error GoTo Fehler .CursorLocation = adUseClient .Mode = adModeShareDenyNone .Provider = "Microsoft.Jet.OLEDB.4.0" .ConnectionString = "Data Source=" & DBName .Open ConnectionOpen = True End With Fehler: If Err.Number <> 0 Then Msg = "Die Verbindung zur Datenbank" & vbCrLf & _ "konnte nicht hergestellt werden " & vbCrLf & vbCrLf & _ Err.Description FehlerAnzeige Err.Number, Msg, "ConnectionOpen" End If On Error GoTo 0 End Function Du solltest einen anderen Namen für die globale Connection verwenden, das kann zu Konflikten kommen, da die ADODB.Connection auch so heißt (Connection). Normalerweise packt man einen Vorschub vor die Variablen: g_DBConnection (g für global). Zudem sehe ich 1. keinen Unterschied in den beiden Varianten, zum anderen hast Du die Frage vergessen... ;-)

Hi, deklarier die Connection in einem Modul : Public g_DBConnection As ADODB.Connection

Naja, wenn Dein Ausbilder meint, dass das so den tollen lerneffekt bringt. Da würde ich ja eher gleich alles mit SQL machen, denn dann hast Du keine Umbauarbeiten mehr. Statt die Arbeit in so einen Kram zu stecken, sollte man die Zeit lieber darin investieren, den DB - Kram in eine Klasse zu kapseln, erleichtert die Arbeit für die nächsten Projekte wesentlich. Meiner Meinung (und andere ebenso) völlig verschenkte Zeit. Wäre ungefähr das Gleiche, als wenn Du die DB - Anbindung erst mit den be****en gebundenen Controls machen würdest und dann die Anwendung auf Code umstellen würdest....

Naja, dann kannst Du Deinem Ausbilder sagen, dass diese Art der Aktualiserung nicht sicher und performant ist. Ich kenne genug Anwendungen, bei denen es damit Probleme gab und ich bewege mich in der Sprache jetzt schon einige Jahre und kenne genug Beispielgeschichten von Programmierern, die VB schon seit VB 1 oder 3 machen. Ist nur ein gutgemeinter Rat, denn wenn Du auf andere DB - Systeme oder mit einer anderen Programmiersprache den Kram machst, dann wirst Du um SQL nicht herum kommen...

Ein bißchen selber nachdenken muss man schon, man sollte die Variablennamen auch beachten: --> Dies ist Dein formweites Recordset, welches für die Property zuständig ist 'Private WithEvents rsKFZ As ADODB.Recordset ' wird zu Private WithEvents [b]m[/b]rsKFZ As ADODB.Recordset Public Property Set KFZ(ByRef rs As ADODB.Recordset) Set mrsKFZ = rs End Property Public Property Get KFZ() As ADODB.Recordset Set rsKFZ = mrsKFZ End Property Zudem immer noch keine Antwort auf diese Frage:

Naja, wenn Du Deine Property so aussieht: Public Property Set KFZ(ByRef rs As ADODB.Recordset) Set mrsKFZ = rs End Property Public Property Get KFZ() As ADODB.Recordset Set rsKFZ = mrsKFZ End Property dann sollte man auch den richtigen Aufruf verwenden: Private Sub cmdCreateData_Click() Call Load(frmKFZ_Neu) ''''' Set frmKFZ_Neu.Recordset = rsKFZ <- Methode nich gefunden ''''' wird zu: Set frmKFZ_Neu.KFU = rsKFZ Call frmKFZ_Neu.Show End Sub Allerdings frage ich mich grade, wozu man Dir Tips gibt, wenn Du sie nicht beachtest::confused: - nicht die ! - Synthax verwenden - Änderungen an der DB über SQL und Connection und nicht über Recordset Für mich absolut unbegreiflich....

Hi, dass macht man am Besten über eine Property ' code für frmKFZNeu Private m_Connection As ADODB.Connection Public Property Set Connection(ByRef vData As ADODB.Connection) Set m_Connection = vData End Property Public Property Get Connection(ByRef vData As ADODB.Connection) Set Connection = m_Connection End Property ' Aufruf Sub OpenKFZNeu Call Load(frmKFZNeu) Set frmKFZNeu.Connection = DeineConnection Call frmKFZNeu.Show End Sub Code ist ungetestet. Allerdings würde ich mir überlegen, die Connection in ein Modul zu packen, dann hast Du Zugriff vom gesamten Projekt aus. Wofür willst Du das Recordset übergeben? Für eine Neuanlage brauchst Du es ja nicht, da man Änderungen über SQL machen sollte.

Die "Recordset.Filter" - Methode arbeitet in manchen Teilen nicht richtig. Zudem muss man darauf achten, das der Filter wieder zurückgesetzt wird (adFilterNone). Ich mache sowas über SQL - Statements... Ich würde Dir auch raten die statt "Rs!FeldName" die "Rs.Fields("Name).ValuE" zu verwenden, denn die "!" - Variante ist sehr fehleranfällig und ein Relikt aus alten Zeiten, dass tunlichst vermieden werden sollte.

Also, hier eine Funktion zum Füllen einer ComboBox: ' fills combobox with specified Recordset Public Function FillComboBox(ByRef Rs As ADODB.Recordset, _ ByRef ctl As ComboBox, _ ByVal sFieldValue As String, _ ByVal sFieldID As String _ ) As Boolean Dim sTmp As String With ctl Call .Clear If (Rs.RecordCount = 0) Then FillComboBox = False Exit Function End If Call Rs.MoveFirst Do While Not Rs.EOF sTmp = GetText(Rs.Fields(sFieldValue).Value) Call .AddItem(sTmp) .ItemData(.NewIndex) = Rs.Fields(sFieldID).Value Call Rs.MoveNext Loop End With FillComboBox = True End Function ' read field value of specified recordset ' handles NULL values Public Function GetText(vDBText As Variant _ ) As String ' NULL value in field If (VBA.IsNull(vDBText)) Then GetText = VBA.Constants.vbNullString Else GetText = VBA.CStr(vDBText) End If End Function ' gets ComboBox Itemdata Public Function GetCboItemData(ctl As ComboBox _ ) As Long On Error Resume Next GetCboItemData = ctl.ItemData(ctl.ListIndex) End Function Zur Erklärung: FillComboBox füllt eine ComboBox Daten aus einem Recordsetobjekt. sFieldValue ist der Wert der angezeigt wird, sFieldID ist das Primärschlüsselfeld aus der Tabelle. Dieses wird in die ItemData Eigenschaft geschrieben und wird zum Filtern verwendet: ' Füllen der ComboBox: Call FillComboBox(Rs, DeineComboBox, "F_registrationnumber", "I_ID") Private Sub ComboBox_Click Dim sSQL As String Dim lID As Long lID = GetCboItemData(ComboBox) If (lID = -1) Then Exit Sub End If sSQL = "SELECT T_KFZ.F_registrationnumber, " & _ "T_KFZ.F_manufacturer, " & _ "T_KFZ.F_type, " & _ "FROM F_KFZ " & _ "WHERE I_ID = " & lID & ";" Dim Rs As ADODB.Recordset Set Rs = New ADODB.Recordset With Rs .ActiveConnection = Cn .CursorLocation = adUseClient .LockType = adLockOptimistic .Source = sSQL Call .Open End With If (Rs.RecordCount = 0) Then Call MsgBox ("Keine Daten gefunden!",vbOkOnly) Call Rs.Close Set Rs = Nothing Exit Function End If ' Werte in TextBox mit Funktion GetText ' wenn ein Recordset.Fields.Value = NULL ist ' dann gibt es einen Fehler, also vorher abfragen Text1.Text = GetText(Rs.Fields("DeinFeld").Value) End Sub So ungefähr müsste es aussehen. Code ist ungetestet, aber die Funktionen sind in leicht abgeänderter Art schon seit Jahren bei mir im Einsatz.