HolzOnkel

editiert durch die moderation, da OffTopic. klärt das bitte per PN ab. danke

Chief Wiggum

..auch wenn es blöd klingt - schon mal in der Hilfe geschaut? Ich werde aus der VB-Hilfe nicht ganz schlau, aber ich kenn mich mit der VB-Syntax auch nicht aus... kann sein, dass Du da eher was findest als ich.

Gruss,

der Onkel

PS: Vielleicht hilft Dir das bei der Suche: unter VFP heisst der Befehl STRTRAN().

...die Gesamtheitliche 1&2 sind wohl für alle gleich... also wenn, dann auch die "Strippenzieher"...

gruss,

der Onkel

....das würde mich aber auch mal interessieren...

Gruss,

der Onkel

Nachtrag:

Hmm, Mist, gleichzeitig...

Egal, aber den Einwand finde ich nicht so gut - das ist keine Lottoziehung, wo man davon ausgehen kann, dass nicht zweimal die selben 6 Zahlen gezogen werden...

Wie lange soll das Referat denn sein?

Welcher Umpfang, welche Stofftiefe?

Gruss,

der Onkel

Moin!

Um ehrlich zu sein - für meinen Geschmack hast Du für jede "Art" des Mediums zu viele Zusatzinformationen, als dass ich das in eine Tabelle packen würde.

An Deiner Stelle würde ich mir eine Artikel-Haupttabelle schaffen, in der neben Namen, Interner ID und (wenn es interessiert) Einzelpreis auch ein Kennzeichen wäre, um was genau es sich dabei handelt (smallint reicht als Feldgrösse aus: 1= Buch, 2=CD, 3=... usw.).

Dann würde ich mir entsprechende Tabellen buch_info, cd_info, usw. erstellen, die die Informationen beinhalten, die Du brauchst - ISBN-Nummer beim Buch, Gesamtlänge und Songanzahl bei der CD, und so weiter.

Ist vom Design her sicher etwas komplizierter, aber es hilft, die Übersicht zu bewahren und man findet im Zweifelsfall schneller, was man sucht - ein Blick in die entsprechende Tabelle reicht.

Gruss,

der Onkel

Hmm... den Feldtyp "Password" kenne ich persönlich gar nicht...

:confused:

Bin mit MySQL nur in Verbindung mit PHP in Berührung gekommen, und in PHP gibt es einen Verschlüsselungsalgorythmus, mit dem man das Ergebnis einfach in ein CharFeld reinklatscht. So hab ich das immer gemacht.

Kann natürlich durchaus sein, dass es da was anderes gibt, was besser funzt... vielleicht sagt das mit dem datentyp "Passwort" einfach nur aus, dass das Feld nicht einfach ausgelesen werden kann oder sowas...

*schulterzuck*

Gruss,

der Onkel

...immer wieder beliebt, das Thema...

Schau mal unter www.slipstick.com nach... die haben sich auf sowas spezialisiert....

gruss,

der Onkel

..worauf ich mich nur wieder wiederholen kann:

Der Datentyp ist abhängig vom Verschlüsselungsalgodingenskirchens. (Langes Wort, das.)

Geht eigentlich mit viel - universell ist sicher char oder varchar, für die Freunde des Überteibens auch der Blob/Text... Longint geht auch... je nachdem, was Du als endergebnis der verschlüsselung abspeicherst.

Wenn Du Interesse an Verschlüsselungsalgorythmen hast, dan schick mir hier einfach ne Message...

gruss,

der Onkel

Nachtrag:

Sicherheit ist relativ. Natürlich kann jeder mit ein bisserl SQL-Erfahrung dann die entsprechenden Felder auslesen. Aber wenn Du das Passwort verschlüsselt abspeicherst, helfen sie aber auch niemandem, der den verschlüsselungsalgorytmus nicht kennt.

..schön beschrieben... aber... welche Sprache? Welche Datenbank? Bei welchem Vorgang?

:confused:

Gruss,

der Onkel

Sorry, da mus sich jetzt widersprechen...

Decodieren würde bedeuten, dass ich das verschlüsselte Passwort wieder in "Reinform" erlange. Das ist mit meiner Methode gar nicht nötig.

Es gibt mehr als genug Methoden der verschlüsselung, nach denen es unmöglich ist, das ursprüngliche Paswort wieder heraus zu bekommen - was auch sinnig ist, sonst wäre es sinnlos, so manches Passwort überhaupt erst zu verschlüsseln...

nicht umsonst geht man an vielen Stellen dazu über, nicht das alte Passwort auszulesen, sondern ein neues darüber zu schreiben. Sonst käme noch der Admin in Versuchung.. :OD

Gruss,

der Onkel

Wieso sollte ich denn bitte das Passwort wieder entschlüsseln? Ich rechne einfach das eingegebene Passwort wieder in eine Zahl um und vergleiche das mit dem Eintrag in der Datenbank... funzt tadellos...

Gruss,

der Onkel

...so sicher wie dein Verschlüsselungsalgorytmus.

Am einfachsten ist es, das Passwort mit Hilfe einer Formel in eine Zahl umzuwandeln. Da kannst DU zwar nie wieder rausrechnen, wie das Passwort vorher hiess, aber Du kannst es in eine Double reinsetzen.

Gruss,

der Onkel

...im Zweifelsfall geht das (laut meinem Ausbilder) in Linux per pipe...

Gruss,

der Onkel

Hoi!

Das wichtigste an der Doku eines FI ist meistens sowieso der Anhang - der Rest ist "nur" eine Werbebroschüre, im Anhang steht meist, was wirklich wichtig ist - und was beweist, wie viel Ahnung der FI hat. Ausserdem kann man einen Anhang fast nach belieben aufblähen - also keine Scheu!

Ausserdem nicht vergessen - die IHK nimmt (angeblich) zur Benotung und Beurteilung von solchen Dokus Fachleute ran. Man kann also davon ausgehen, dass die geläufigsten Fachbegriffe bekannt sind. Wer TCP/IP oder ODBC in seinem Anhang oder der Doku selbst erwähnt, muss wohl Lücken füllen.. :OD

Gruss,

der Onkel

Moin!

Also, ob ICH-Form oder nicht, das zeigt sich spätestens in der Mündlichen - jemand kann eine noch so gute Doku abgeliefert haben, wenn er/sie sein eigenes Program (bei den AE) nicht kennt, dann ist das relativ lächerlich - insofern denke ich, dass die ICH-Form, es vom Standpunkt "er/sie hat es alleine gemacht" weder besser noch schlechter macht. Was aber mit Sicherheit gesagt werden kann, ist, dass die "ICH-Form" in einer Doku dumm aussieht... "Es werden für das Programm folgende Datenbanken angelegt" hört sich halt imer noch professioneller an, als die ICH-Form.

Gruss,

der Onkel

Hai!

Ich würde den Punkt "Zeitplan" persönlich allerdings in den Anhang legen... da verbraucht er nicht Platz, den man für die Präsentation oder die Doku braucht... die Seitenzahl ist ja begrenzt und wenn man sich ein wenig auslassen will, dann sind die paar Seiten Vorgabe von der IHK schnell voll - ich habe noch nicht mal richtig angefangen und hab schon 8 Seiten. *seufz* War auch blöd, mir so ein Umfangreiches Thema zu wählen...

Gruss,

der Onkel

Schalömsche!

Das ich das noch erleben darf... jemand, der auch die Sprache hat.. *lach*

Die 6.0-Version habe ich, mit der ich arbeiten muss... meine Idee war, dass ich dem Anwender einen TreeView biete, neben einem...hmm... sagen wir mal "Kundennamen" auch ein Kontingent anzeigt, was dieser Kunde zu kaufen hat (z.B. um seine Rabatte zu wahren). Dieses Kontingten sollte variabel gehaten sein, weil es sich ja (laut Vorgabe des Geschäftsführers) von Monat zu Monat ändern kann.

Deswegen meine Idee mit der TextBox... ich habe es bisher noch nicht geschafft, und ich wollte keinen eigenen TreeView coden...

Gruss,

der Onkel

..im Zweifelsfall: frag einfach ab, ob der Rückgabewert NULL ist. So nen ISNULL-Befehl gibt es wohl in jeder Programiersprache...

Gruss,

der Onkel

.hmm... weiss ich auch nicht so genau, aber eines ist sicher: Du solltest dabei erstmal alle Office-Anwendungen als erstes schliessen, weil XP nicht runrterfährt, bevor die dicht sind...

Gruss,

der Onkel

..sorry,war eine Woche unterwegs.

Ja, richtig, der MS-SQL-Server kann pro Befehl nur eine gewisse Anzahl von Zeichen aufnehmen.

Aber:

1) Eigentlich kannst Du pro Auftrag doch mehrere Schritte durchführen lassen - reicht das dann trotzdem nicht?

2) Wenn nicht - bist Du sicher, dass man den SQL-Befehl nicht komprimieren kann?

3) Anderer Weg: mehrere Aufträge hintereinander starten? So im 10 min-Abstand oder sowas?

Gruss,

der Onkel

Original geschrieben von DePlague

über was für ein SELECT frage ich ein Feld des Typs SMALLDATETIME, nach Monaten oder Jahren ab?

Und wie kann ich das nach Jahren sortieren?

Schalömsche!

Der Select - ähm...

SELECT <feldname> FROM <tabelle> ? Oder was meinst Du?

Nach Jahren sortiert geht mit:

SELECT <feldname> FROM <tabelle> ORDER BY YEAR(<feldname>)

Gruss,

der Onkel

Original geschrieben von Olli_Master

Das machst du mir aber mal bitte vor (nur Standard-SQL) - datenbankunabhängig.

Mist... ich hab es vorhin ausprobiert, funzt leider nicht so ganz wie ich das wollte.. *seufz*

Andere Idee:

Bau deinen View mit einem OUTER JOIN auf:

CREATE VIEW ViewName AS

SELECT irgendeineTabelle.satz_nr, tabelle1.Feld1, tabelle1.Feld2 ...

FROM tabelle1 FULL OUTER JOIN irgendeineTabelle ON 1=1

INNER JOIN tabelle2 ON tabelle1.LinkField = tabelle2.LinkField

...

Und so weiter... ich habe jetzt keine "echte" SQL-Datenbank zur Hand, mit der ich dsa testen könnte, ist nur so eine Idee... einfach mal ausprobieren, könnte klappen...

Gruss,

der grübende Onkel

Original geschrieben von hades

Ja, das kommt aber wie Du schon sagtest auf das verwendete DBMS an.

Nicht jedes DBMS unterstuetzt Views.

Ach ja.. ich vergass... Standards sind ja für manche dazu da, nicht eingehalten zu werden... :OD

Wie dem auch sei - welche Datenbank isses denn nun?

gruss,

der neugierige Onkel

Hmm... kommt wirklich auf die Datenbank an.

Wie wäre es mit einem View, dem Du eine eigene Identity-Spalte gibst?

Ist, finde ich, die problemloseste Version für alle Datenbanken...

Gruss,

der Onkel