Verbindung zu Datenbank.

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
becker_stutt
User
Beiträge: 4
Registriert: Donnerstag 12. September 2019, 15:46

ich habe ein klein_Tool Code geschrieben und ich bekomme dieser Fehler, wenn ich mich an den System melden will.

Fehler :
Warning (from warnings module): File "C:\Users\BTODEMF\AppData\Local\Programs\Python\Python37\lib\site-packages\jpype\_core.py", line 210 """)

UserWarning:
-------------------------------------------------------------------------------
Deprecated: convertStrings was not specified when starting the JVM. The default
behavior in JPype will be False starting in JPype 0.8. The recommended setting
for new code is convertStrings=False. The legacy value of True was assumed for
this session. If you are a user of an application that reported this warning,
please file a ticket with the developer.

was ist hier das Problem ?
__deets__
User
Beiträge: 14522
Registriert: Mittwoch 14. Oktober 2015, 14:29

Das ist ja kein Fehler. Sondern eine Warnung. Und was man tun soll sagt sie: eine convertString-Option explizit angeben. Da du das bisher nicht gemacht hast, solltest du convertStrings=True setzen. Damit das Verhalten gleich bleibt auch nach einem Upgrade auf JPype 0.8.

Hast du das mal gegoogelt?
becker_stutt
User
Beiträge: 4
Registriert: Donnerstag 12. September 2019, 15:46

Ja, gegooglet habe ich, aber die Lösung bis jetzt funktioniert nicht.
__deets__
User
Beiträge: 14522
Registriert: Mittwoch 14. Oktober 2015, 14:29

Wie genau hast du das denn probiert?
becker_stutt
User
Beiträge: 4
Registriert: Donnerstag 12. September 2019, 15:46

danke Problem ist gelöscht.
becker_stutt
User
Beiträge: 4
Registriert: Donnerstag 12. September 2019, 15:46

ich habe ein String durch Konkatenation von String bekommen und ich will das später in einer SQL request nutzen. wie kann ich das lösen, wenn das String viel zu große ist. ich will die Dateien später exportieren ??
''useridstr'' ist viel zu große



useridstr = ''
i = 0
for userid in exportUserids:
if i == 0:
useridstr = useridstr + '\'' + userid + '\''
else:
useridstr = useridstr + ', \'' + userid + '\''

i = i + 1

sql = """SELECT BENU, NAME, EMAIL, ABT, TEL
FROM BABENU
WHERE BENU IN (
"""+useridstr+"""
);"""
users = query_database(sql, True)
for user in users:
userid = user[0].strip()
userdata[userid] = {'userdata' : {'benu': user[0].strip(), 'name': user[1].strip(), 'email': user[2].strip(), 'department' : user[3].strip(), 'phone': user[4].strip()}}
__deets__
User
Beiträge: 14522
Registriert: Mittwoch 14. Oktober 2015, 14:29

Bitte Code-Tags benutzen. Und SQL stueckelt man nicht mit String-Operationen zusammen, sondern benutzt die parametrisierte Form von execute. Einen Index in einer Schleife verwaltet man auch nicht selbst, sondern sagt einfach

Code: Alles auswählen

for i, userid in enumerate(export_userids):
Namenskonvention bei Variablen ist klein_mit_unterstrich, CamelCase ist fuer Klassennamen. Und zu guter Letzt: BENU, ABT, TEL kann man auch BENUTZER, ABTEILUNG, TELEFON nennen, Code wird mehr gelesen als geschrieben. Womit klare, gute Namen wichtig sind, nicht das einsparen von Tastendruecken. Und der Datenbank ist die Laenge der Bezeichner egal.
Sirius3
User
Beiträge: 17737
Registriert: Sonntag 21. Oktober 2012, 17:20

Was für eine Datenbank ist das? Was heißt "viel zu groß"?

Zum Code: man stückelt keine Strings mit + zusammen und für Listen gibt es join:

Code: Alles auswählen

user_ids = ', '.join(map('"{}'".format, export_userids))
Ganz falsch ist es, Parameter ins SQL-Statements hineinzuformatieren. Dazu gibt es Platzhalter. Je nach Datenbank-Anbindung können diese sich unterscheiden, könnte also z.B. so aussehen:

Code: Alles auswählen

sql_statement = f"SELECT benu, name, email, abt, tel FROM babenu WHERE benu in ({','.join('?'*len(export_userids)})"
cursor.execute(sql_statement, export_userids)
Was ist dieses `query_database`?

Auch bei Datenbanken sollte man unsinnige Abkürzungen vermeiden. Warum `BENU` und nicht `benutzer`? Warum `abt` und nicht `abtei`? Und was soll das `BA` in `BABENU` bedeuten? Daher die dringende Empfehlung, bevor Du viel Code produzierst, den Du dann nachträglich ändern mußt, erst einmal das Datenbankdesign reparieren.

`userdata` scheint ein Wörterbuch zu sein. Was ist der Sinn, in jeden Wert nochmal ein Wörterbuch mit nur einem Schlüssel "userdata" zu stecken? Der kann weg. Die Daten in der Datenbank sollten schon keine unnötigen Leerzeichen enthalten. Du ganzen Strip können weg.
Benutzeravatar
__blackjack__
User
Beiträge: 13068
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@becker_stutt: `useridstr` würde man so nicht in Python erstellen. Das wäre einfach

Code: Alles auswählen

     user_ids_string = ",".join(f"'{user_id}'" for user_id in export_user_ids)
Allerdings formatiert man keine Werte selbst per Zeichenkettenformatierung in SQL-Abfragen. Das ist im besten Fall nur unperformant und im schlechtesten Fall gefährlich, weil man sich da eine Sicherheitslücke ins Programm reisst.

In die SQL-Zeichenkette gehören Platzhalter und die Werte werden als zweites Argument von `Cursor.execute()` übergeben.

Das man bei den Daten aus der Datenbank `strip()` aufrufen muss, sieht komisch aus. In der Datenbank sollten ”saubere” Daten vorliegen. Solche bereinigungen macht man bevor man die Daten einfügt. Insbesondere beim `userid`-Wert sieht das falsch aus, weil es auf diese weise passieren kann das im `userdata`-Wörterbuch Werte überschrieben werden können‽ Dann ”überlebt” ein zufälliger Datensatz. Soll das wirklich so sein?

Statt magischer Indexzugriffe wäre es lesbarer wenn man die Werte in der Schleife bereits auf Namen verteilen würde.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Antworten