Variabler Datenbank-Zugriff - Problem mit Stringumwandlung

[hberdel]

Hallo, ich möchte Code sparen und versuche deshalb, beim Speichern der eingegebenen Daten auf jeweils eine von zwei gleich aufgebauten Tabellen mit unterschiedlichen Daten umschalten zu können. Die eine Tabelle (QueryPreise) enthält die Preise des laufenden Jahres, die andere die Preise des nächsten Jahres (QueryPreiseNeu).

Momentan sieht das so aus unter Verwendung von nur einer Tabelle:

Delphi-Quellcode:

Var Preis1 : Variant;

    Preis1 := FData.QueryPreiseSsNeben.Value;

Was ich probiere:

Delphi-Quellcode:

    If Jahr = RefJahrString then PrsAltNeu := 'QueryPreise';
    If Jahr = NxtJahrString then PrsAltNeu := 'QueryPreiseNeu';

    Preis1 := 'FData. + PrsAltNeu + SsNeben.Value';

Die Teile werden auch richtig zusammengesetzt aber ich bekomme dann die Fehlermeldung:

"Variante des Typs (String) konnte nicht in Typ (Double) konvertiert werden.

Wäre schön, wenn jemand "hier" schreit . . .

[edit=mkinzler]Delphi-Tags eingefügt Mfg, mkinzler[/edit]

[DeddyH]

Hallo und Willkommen in der DP ,

Zitat:

Preis1 := 'FData. + PrsAltNeu + SsNeben.Value';

Du hast den ganzen Ausdruck in einem String, das kann so nicht einer Zahl zugewiesen werden. Funkioniert es, wenn Du die Hochkommata weglässt?

[hberdel]

Nein, das mag der Compiler schon nicht.

[DeddyH]

Achso, jetzt hab ich das Problem erst verstanden. Neuer Ansatz:
Preis1 := (FData.FindComponent(PrsAltNeu + 'SsNeben') as TQuery).Value; Das ist jetzt aber nur ein Test ohne Fehlerbehandlung, ich möchte nur sehen, ob ich Dich richtig verstanden habe.

[hberdel]

Compiler sagt : Undef Bez : Value

[mkinzler]

Dann hast du irgendeine Klammer falsch gesetzt o.ä. Zeig mal die Codezeile.

[hoika]

Hallo,

nicht nur die Code-Zeile, sondern am besten das ganze Form.
Ich glaube nämlich, dass QueryPreiseSsNeben gar keine Query ist,
sondern ein persistentes Feld.

Ein Query.Value gibt es doch gar nicht.

# Update :#
Edit: Paradox ? ui :=)

Wie wird denn gespeichert, mit TTable ?
Übergib dann das TTable einfach einer Speicherprozedur
und verabschiede dich von den persistenten Feldern.


Heiko

[DeddyH]

Zitat von hoika:

Ein Query.Value gibt es doch gar nicht.

Das war mir nachträglich auch eingefallen, aber da der ursprüngliche Typ mir nicht bekannt ist, hab ich es erstmal so gelassen.

[hoika]

Hallo,

was mir hier noch auffällt.

Zitat:

Die eine Tabelle (QueryPreise) enthält die Preise des laufenden Jahres, die andere die Preise des nächsten Jahres (QueryPreiseNeu).

Gaaanz schlechtes DB-Design !!!

Was ist 2011, noch eine Tabelle, QueryPreiseNeuNeu ??

Packe alle Preis in eine Tabelle mit dem Jahr als (Integer)-Feld.


Heiko

[hberdel]

Hallo alle, schön, dass ihr mir helfen wollt . . .
Natürlich ist das eine TQuery mit Namen "QueryPreise" und wie schon vorher zitiert können die Werte der Datenfelder mit QueryPreisexxx.Value ausgelesen bzw. gespeichert werden.

QueryPreise und QueryPreiseNeu besitzen 9 Datenfelder, die ich nach Vorschlag von hoika alle doppeln müsste. Da wäre es einfacher, meine vorhandene Struktur zu verzweigen . . .

Zum Verständnis: Ich benötige die Preise 2009 nächstes Jahr nicht mehr. Aber in 2009 mache ich sowohl noch Mietverträge für 2009 als auch schon für 2010. In 2010 übernehme ich die Daten von 'QueryPreiseNeu' in 'QueryPreise' und kann dann in 3-4 Jahren problemlos wieder eine Preiserhöhung mit 'QueryPreiseNeu' machen, wenn nötig.

DeddyH : Ich habe deine Code-Zeile kopiert und somit ohne Änderung in meinen Quellcode eingefügt.

begin
Preis1 := (FData.FindComponent(PrsAltNeu + 'SsNeben') as TQuery).Value;
case AnzPers of
3 : Zuschlag1 := FData.QueryPreiseNeuZuNeben.Value;
4 : Zuschlag1 := FData.QueryPreiseNeuZuNeben.Value') * 2;
5 : Zuschlag1 := FData.QueryPreiseNeuZuNeben.Value') * 3;
6 : Zuschlag1 := FData.QueryPreiseNeuZuNeben.Value') * 4;
7 : Zuschlag1 := FData.QueryPreiseNeuZuNeben.Value') * 5;
8 : Zuschlag1 := FData.QueryPreiseNeuZuNeben.Value') * 6;
end;

Wenn's zu viel Mühe macht, habe ich auch eine andere Lösung, wie schon erwähnt, aber der Ehrgeiz . . . das müsste doch funzen - oder?