JRPC3 - neuer Präkompiler für XProfan

Deine Links sind leider nicht zu erreichen ????

Danke

Hallo Jens, danke noch mal für deinen genialen PraeCompiler!

Wenn ich in SQL Abfragen die Variablen Einbettung nutze funktioniert das leider nicht mit den kurzen Variablen. Das kann ich natürlich umgehen mit {$NoShortNames} Damit funktioniert dann alles wie gewünscht.

Beispiel:

SQLUpdateOrder = "BEGIN TRANSACTION
UPDATE Z_DEXORDERS SET TRANS_CD = '04' where ex_ord_no_source = :ex_ord_no_source; COMMIT"

Das funktioniert nur mit {$NoShortNames} oder wenn ich die Variable so wie hier in Hochkomma setze.

SQLUpdateOrder = "BEGIN TRANSACTION
UPDATE Z_DEXORDERS SET TRANS_CD = '04' where ex_ord_no_source = ' "+ex_ord_no_source+" ' COMMIT"

Mit {$Declare String ex_ord_no_source} funktiniert es auch nicht. Gibt es noch andere Möglichkeiten?

Zitat von Jens-Arne

Und ich habe gerade festgestellt, dass weder XProfan noch JRPC3 mit Arrayvariablen als embedded strings umgehen können. Das könnte ich mal angehen.

Auch von mir frohe Weihnachten miteinander.

Das hatte RGH irgendwo in den Foren schon gesagt, daß nur einfache Variablen gehen.

Ich denke, das ist auch nur eine Ersetzung, ähnlich wie die Escape-Sequenzen. Bei Arrays,

Bereichen bzw. Strukturen wird das wohl schwierig. Welcher Teil vom Bereich bzw. Array

ist gemeint ? Dann höchstens eher sowas \:blub[0];

Guten Morgen!

Allen noch Frohe Weihnachten gehabt zu haben

Ich benutze es wie in der Hilfe beschrieben. Im Prä-Compilermodus O funktioniert das Siehe Hilfe

Damit funktionieren auch Arrayvariablen das habe ich schon probiert, also so etwas wie :Suche[0]; auch ohne Hochkomma... Mit PostFix geht das zum Beispiel nicht... (:Suche$[0])

Das Semikolon war tatsächlich nicht für das Commit sondern für die embeddet Variable.

Viele Grüße und danke für eure Mühe das hier am leben zu erhalten!

PS: Update mache ich heute wenn ich wieder arbeite

Aber in reinem XProfan geht es doch nicht.

Declare D$[4], String S[4], a, b, c, d
S[0] = "Heinz,"
S[1] = "bist"
S[2] = "du"
S[3] = "da ?"
D$[0] = "Heinz,"
D$[1] = "bist"
D$[2] = "du"
D$[3] = "da ?"
a = "Heinz,"
b = "bist"
c = "du"
d = "da ?"
Cls
Print "Hallo \:S[0]; \:S[1]; \:S[2]; schon \:S[3];"
Print "Hallo ", S[0], S[1], S[2], "schon ", S[3]
Print "Hallo \:D$[0] \:D$[1] \:D$[2] schon \:D$[3]"
Print "Hallo \:a; \:b; \:c; schon \:d;"
Waitkey

Guten Morgen,

ich muss mich entschuldigen..

Es steht sogar in der Hilfe bei den Escape-Sequenzen

Aber warum funktioniert das dann nur so? Mit dem "\" davor geht es weder mit SQLite noch mit MSSQL oder MySql.

{$NoShortNames}
WindowStyle 10 + 16 
Window 800,600
UseIcon "WINDOWS"
Color 10,0
CLS 10,0
Font 0
WindowTitle "DB Eingebettete Variablen Sql Test"

Declare int slDll
slDll = db("slUseDll","sqlite3.dll") 'neueste sqlitedll

Declare Int hdb 'Handle der Datenbank
Declare String art_no[]
art_no[0] = "500505"
art_no[1] = "500506"

Erase "Test.db" 'Tabelle löschen falls sie schon da ist

hdb = db("slCreate","Test.db") 'Datenbank anlegen
db("slExec",hdb,"Create Table BARTICLES (art_no NUMERIC,desc_1 char(40),desc_2 char(40))",1)

db("slExec",hdb,"Insert into BARTICLES (art_no,desc_1,desc_2) values ('500505','TestArtikel1','TestArtikel1')",1)
db("slExec",hdb,"Insert into BARTICLES (art_no,desc_1,desc_2) values ('500506','TestArtikel2','TestArtikel2')",1)

db("slExec",hdb,"select art_no,desc_1,desc_2 from BARTICLES where art_no = :art_no[0]; or art_no = :art_no[1];",0)

WaitInput

db("slDone",hdb)
Erase "Test.db" 'Aufräumen

Heinz: Ich denke die eingebetteten Variablen werden nur im SQL übersetzt.

Ich habe die neueste sqlite dll angehängt die muss in dem Verzeichnis liegen.

Zitat von A.Berse

Ich denke die eingebetteten Variablen werden nur im SQL übersetzt.

Normalerweise wird das ja VOR slExec übersetzt und dann dieser ersetzte

String übergeben. Das ist ja Sinn und Zweck dieser Sache.

Meinst du im String selbst?

So wie ich es bisher immer benutze und in der SQL Hilfe steht, werden die Variablen beim Übertragen an den sql server eingebettet. Nicht davor.

Ein übersetzen davor müsste nach den normalen Regeln erfolgen mit Hochkomma etc.

So wie hier:

declare String art_no

declare String SQLAbfrage

SQLAbfrage = "Select art_no,desc_1,desc_2 from Barticles where art_no = ' "+art_no+" ' "

db("sqlexec",SQLAbfrage,0)

Mit den Embedded Variablen habe ich es seit jeher so gemacht wie es in der Hilfe im Abschnitt SQL steht nur mit :$ oder :; ohne dem \ davor.

Hast du mal den Code oben ausprobiert?

VG

Ja, der Code funktioniert so, wie in deinem Beispiel.

Ich habe jetzt auch mal bei SQLExec in der Hilfe nachgelesen.

Das scheint dann nochmals ein spezielle Variante, eben für SQLExec, zu sein.

Es gibt ja auch noch andere Situationen, bei denen embedded Vars nützlich

sind. Da hätte RGH das einheitlich regeln müssen.

Schade das Roland nicht mehr reagiert.. Weiß jemand wie es ihm geht?

Ich habe gerade mit "normalen" Embedded Variablen gespielt:

'Funktioniert:
Declare VName$
VName$ = "Axel Berse"
Print "Hallo \:VName$"

'Funktioniert nicht:
Declare VName$[]
VName$[0] = "Axel Berse"
Print "Hallo \:VName$[0]"

'Funktioniert nicht:
Declare String VName[]
VName[0] = "Axel Berse"
Print "Hallo \:VName[0]"


'Funktioniert im direkten Sql:
Declare String VName[]
VName[0] = "Axel Berse"
Print "Select * from namen where name = :VName[0]; "

'Funktioniert nicht im direkten Sql:
Declare VName$[]
VName$[0] = "Axel Berse"
Print "Select * from namen where name = :VName$[0] "

'Funktioniert im direkten Sql:
Declare VName$
VName$ = "Axel Berse"
Print "Select * from namen where name = :VName$ "

'Funktioniert nicht im direkten Sql:
Declare VName$
VName$ = "Axel Berse"
Print "Select * from namen where name = \:VName$ "

'Funktioniert im vor-übersetzten Sql: ()
Declare VName$
VName$ = "Axel Berse"
Print "Select * from namen where name = " ' "+VName$+" ' "

'Funktioniert im vor-übersetzten Sql: ()
Declare String VName[]
VName[0] = "Axel Berse"
Print "Select * from namen where name = " ' "+VName[0]+" ' "

Zitat von A.Berse

Schade das Roland nicht mehr reagiert.. Weiß jemand wie es ihm geht?

Die letzten Monate scheint er gar nicht mehr hier im Forum gewesen zu sein.

Ich schaue hier öfter bei den Mitgliedern unter Benutzer online. Sonst konnte ich

ein paar mal die Woche sehen, daß er online war, wenn auch nicht immer hier in

der Profan-Abteilung.

Bin ich ehrlich gesagt von ihm nicht gewöhnt, daß er wortlos hier die Bühne verläßt.

Vielleicht ist er auch krank geworden und es ist ihm nicht (mehr) möglich, hier was

zu schreiben oder sich überhaupt PC-mäßig einzuloggen. Da können wir als Außenstehende

nur vermuten.

Zitat von Jens-Arne

Ich wusste nicht, dass es da eine spezielle Variante für SQL-Statements gibt.

Ich vermute das jedenfalls mal.

Darum, weil es mit SQL geht und mit normalem XProfan eben nicht.

Kann ja sein, daß die Exec-Befehle eine Sonderbehandlung erfahren.

Guten Morgen zusammen Hier muss sich keiner entschuldigen.. jens!

Ich benutze die internen Variablen schon länger nur mit prä und suffix also :$ aber bei einem Test war mir aufgefallen das die Arrays ohne suffix auch im direkten sql funktionieren. Das hat mich natürlich gefreut.. Die sql abfragen / Transactions lege ich seit längerem in einer DLL ab, diese sind dann mit einem pw verschlüsselt. Damit kann ich an diesen arbeiten, ohne in den Code eingreifen zu müssen.

Also kann man quasi xprofan variablen direkt an den sql Server übergeben.

So wie hier werden Laborwerte von einem vorgelagerten System in unser ERP System übertragen. Es geht nur um den oberen Teil wo die SQL Variablen deklariert und mit denen aus XProfan gefüllt werden.

Das hier jetzt aber eben auch Array Variablen funktionieren, freut mich sehr damit kann ich noch mal mehr machen.

BEGIN

  declare @val_input as DECIMAL(15,2) = :val_input$
  declare @spec_no as varchar(20) = :spec_no$
  declare @musternummer as varchar(20) = :musternummer$
  declare @plant_no as decimal(3,0) = :plant_no$

UPDATE [dbo].[z_RMUvw_ABE_QORDITEMS_SAVE] SET 
  val_input = @val_input,
  val_input_1 = @val_input,
  input_yn = '-1'

where z_id_temp_no = @musternummer
and 
  date_cre >= format(current_timestamp,'yyyMMdd') 
and
  test_status = '11'
and
  spec_no = @spec_no
and
  z_plant_no = @plant_no


UPDATE [dbo].[z_RMUvw_ABE_QORDITEMS_SAVE]
SET complies_cd = 

CASE

WHEN 
  up_limit_2 is NULL and  @val_input >= low_limit_2 
  then '10'

when -- Wenn oberhalb Low_limit_2  und unterhalb up_limit_2 und up_limit nicht 'NULL ist' 
  @val_input >= low_limit_2 and @val_input <= up_limit_2  and up_limit_2 is not NULL
  then '10'  

when -- Wenn oberhalb low_limit_2 und oberhalb up_limit 2 und uplimit 2 nicht NULL ist
  @val_input >= low_limit_2 and @val_input > up_limit_2  and up_limit_2 is not NULL
  then '90'  

when -- Wenn unterhalb low Limit 2 und unterhalb up_limit 2 und uplimit nicht null ist
  @val_input <= low_limit_2 and @val_input < up_limit_2  and up_limit_2 is not NULL
  then '90'  

when  --Wenn unterhalb low_limit und unterhalb up_limit 2 und up_limit 2 ist NULL
  @val_input <= low_limit_2 and @val_input <= up_limit_2  and up_limit_2 is NULL
  then '90'

END
where z_id_temp_no = @musternummer
and 
  date_cre >= format(current_timestamp,'yyyMMdd') 
and 
  test_status = '11'
and 
  spec_no = @spec_no
and
  z_plant_no = @plant_no

END;