Laden...

Forenbeiträge von sklopskoff Ingesamt 10 Beiträge

15.09.2013 - 13:35 Uhr

ListViewItem hat keine Eigenschaft "Length".
Die Anzahl der Elemente in einem Listview ermittelt man mit "ListView.Items.Count".

Grüße,

Christoph

22.08.2013 - 07:46 Uhr

Dies ist vielleicht hilfreich:
using-stored-procedure-output-parameters-in-c-sharp

Ist es übrigens gewollt, nur eine "id_neu" (die letzte!) zurückzuerhalten, obwohl dein Konstrukt ggf. mehrere Prozeduraufrufe (entsprechend der Anzahl der Zeilen in "ds.Tables[0]") durchführt?

Grüße,

Christoph

22.08.2013 - 07:04 Uhr

Hallo diana!

Wie sieht deine gespeicherte Prozedur aus?
Wo fügst du dem Command den Output-Parameter zu?

Grüße,

Christoph

19.07.2013 - 07:05 Uhr

Happy Birthday!

10 Jahre sind eine Ewigkeit in der IT-Welt...

25.11.2012 - 11:46 Uhr

Ich bezweifle, dass das was du vorhast, möglich ist.
Meines Wissens werden Windows-Kennwörter schon auf dem Client verschlüsselt.
Selbst wenn du den Kennwort-Hash auf dem Domänen-Controller abfangen könntest, würde
er dir in anderen Systemen wie Notes nichts nützen.

Die einzige Chance die du m.E. hast, ist es, Kennwortänderungen an allen beteiligten Systemen zu verhindern (geht das überhaupt?) und ein eigenes Interface mit angeschlossener Kennwort-Hash-Datenbank bereitzustellen, das dann ggf. die Kennwörter aller Anwendungen ändert.
Ein Datensicherheitsalbtraum!

Grüße,

Christoph

18.09.2012 - 06:43 Uhr

Hallo Steven85!

Du musst Cell.CellReference auswerten, um herauszufinden, zu welcher Spalte eine Zelle gehört. CellReference enthält die typische Excel-Zellennotation, z.B. "B5" für Spalte 2 /Zeile 5.

Grüße,

Christoph

03.06.2012 - 12:50 Uhr

Erweitere die Select-Abfrage:

SELECT * FROM Mitarbeiter WHERE Username = <eingegebener Benutzername> AND passwort = <eingegebenes Passwort>

Wenn kein Satz gefunden wird, ist die Anmeldung falsch.

Wenn ein Satz gefunden wird, ist die Anmeldung richtig.

Wenn mehr als ein Satz gefunden wird, stehst du auf dem Schlauch.

Ich finde es verwirrend, dass ein Benutzername mehrfach vorkommen darf.

Grüße,

Christoph

31.05.2012 - 12:29 Uhr

Hallo Cr95is,

Leider kann ich dir auch nicht sagen, wo die Ursache für dein Problem liegt.
Möglicherweise ist der Fehler bei der Datenquelle des GridViews zu suchen.
Ich vermute, es handelt sich dabei um die Tabelle einer Datenbank.

Grundsätzlich stellt sich mir die Frage, warum die Daten (z.B. den Url zum User-Bild und vermutlich noch einige andere in den Funktionen changeLink() und changeDate()), die du auf so komplizierte und zeitraubende Weise nachträglich ermittelst, nicht von vornherein Teil der Datenquelle des GridViews sind ?

Dies könnte z.B. durch einen Join der Tabellen u_users und der Tabelle "wasweissich" (vmtl. "Userposts" oder so...), die Datenquelle des Gridviews ist, erreicht werden.

Dann wäre das nachträgliche Ändern des GridViews unnötig und du sparst massenweise Datenbankzugriffe ein.
Vielleicht verschwindet auf diese Weise auch dein Problem. 😁

Grüße,

Christoph

26.05.2012 - 09:15 Uhr

Warum suchst du nicht mit dem eingegebenen Benutzernamen in der Mitarbeiter-Tabelle und vergleichst das Kennwort aus dem ggf. gefundenen Datensatz mit dem eingegebenen Kennwort?

(SELECT Passwort FROM Mitarbeiter WHERE Username = <eingegebener Benutzername>)

Die ID brauchst du für diese Abfrage doch offensichtlich garnicht.

Wenn allerdings der Benutzername in der Mitarbeiter-Tabelle nicht eindeutig ist, bekommst du ganz andere Probleme.

Grüße,

Christoph

22.05.2012 - 19:14 Uhr

Hallo Russell!

Meiner Meinung nach entscheiden einzig und allein die Anforderungen der Nutzer der erstellten Dokumente, welches Ausgabeformat die Office-Dokumente haben müssen.
"state-of-the-art" ist ja ohnehin nur ein Marketing-Begriff ( 😉).

Da aber auch Word 2003 ohne weiteres zur Verwendung von docx ertüchtigt werden kann, spricht nichts gegen die Verwendung von Open XML, um Dokumente zu erzeugen.
Am einfachsten für den Entwickler ist es allemal und vermutlich auch zukunftssicher...

Grüße,

Christoph