SQL Custom and Eval / Parse (and \!\!\!...)

[#1]

Hi!

I do a lot of queries that can't use the JMP query builder and have to be written in SQL Custom.
But as I also want to generalize my code I have to integrate a lot of eval / inserts and \! 

Here is an example:

Code not yet generalized

New SQL Query(
	Connection(
		"ODBC:blabla"
	),
	QueryName( "v_test_run" ),
	CustomSQL(
		"SELECT \!"t1\!".lot_id 
		FROM \!"public\!".\!"v_test_run\!"  \!"t1\!" 
		WHERE  (  (  ( \!"t1\!".test_run_timestamp >= '2020-11-01 15:25:11' )  )  ) ;"
	)
) << Modify;

Code Generalized to include a date:

gbStr = Eval Insert("

New SQL Query(
	Connection(
		\!"ODBC:blabla\!"
	),
	QueryName( \!"v_test_run\!" ),
	CustomSQL(
		\!"SELECT \!\!\!"t1\!\!\!".lot_id 
FROM \!\!\!"public\!\!\!".\!\!\!"v_test_run\!\!\!"  \!\!\!"t1\!\!\!" 
WHERE  (  (  ( \!\!\!"t1\!\!\!".test_run_timestamp >= '^date_deb^' )  )  ) ;\!"
)
) << Modify;


");
Eval( Parse( gbStr ) );

Is there any other method that would save me from having to juggle with these \!\!\! symbols?

On complex scripts it's really difficult to handle and debug!

Thank you

[#2 · Accepted solution]

There are a few options outlined in this article, I recommend starting with Eval( Eval Expr()) and then wrapping each piece you need to replace with Expr(), and using \[ ... ]\ to reduce the number of escaped characters.  It could look something like this:

Eval( Eval Expr(
	New SQL Query(
		Connection(
			"ODBC:blabla"
		),
		QueryName( "v_test_run" ),
		CustomSQL(
			Expr( "\[SELECT "t1".lot_id 
			FROM "public"."v_test_run"  "t1" 
			WHERE  (  (  ( "t1".test_run_timestamp >= ']\" || date_deb || "' )  )  ) ;")
		)
	) << Modify
) );

[#3]

Thank you very much! I had read this article and had tried but I still have difficulties in mastering this eval (eval expr (expr))

[#4]

I agree that this syntax is only obvious once you understand it, and even then it is confusing.  Check out this wish list item to introduce an Eval Expr First() function, maybe that would be more intuitive?

[#5]

I would use the delimiters \[ and ]\ to include double quotes in the string.  

date_deb = "to_date('01-Mar-2019', 'dd-mon-yyyy')";
gbStr = Eval Insert("\[
New SQL Query(
	Connection(
		"ODBC:blabla"
	),
	QueryName( "v_test_run" ),
	CustomSQL(
		"SELECT "t1".lot_id 
FROM "public"."v_test_run"  "t1" 
WHERE  (  (  ( "t1".test_run_timestamp >= ^date_deb^ )  )  ) ;"
)
) << Modify;
]\");

write(gbstr);

Eval( Parse( gbStr ) );

Output:

New SQL Query(
	Connection(
		"ODBC:blabla"
	),
	QueryName( "v_test_run" ),
	CustomSQL(
		"SELECT "t1".lot_id 
FROM "public"."v_test_run"  "t1" 
WHERE  (  (  ( "t1".test_run_timestamp >= to_date('01-Mar-2019', 'dd-mon-yyyy') )  )  ) ;"
)
) << Modify;

[#6 · Accepted solution]

I like to follow a different path avoiding unintuitive eval parse combinations, where I find them quite useful for other purposes.

Often I have complex queries (built in plain SQL by other Tools like SQL developer). And I Need to modify some variables.

The attached example Shows how it works with big class datatable, howewer it would work for all ODBC Connections in a similar way.

Simply I prepare my Connection string (not used here) and the SQL Query in a string variable, given to the "New SQL Query".object.

I use "assign" (instead of "=") because it works nice for large queries and Code folding.

And I'm more flexible for also using open database function, or processing the SQL in other ways.

Usually the double quotes are not needed in a plain SQL (and I try to avoid also), unless you have names with spaces etc. like "Big Class".

Names Default To Here( 1 );

cdt = Open( "$Sample_Data\Big Class.jmp" );
age = "15";

// define custom SQL with placeholder
Assign( sql_str, "SELECT t1.name, t1.age, t1.sex, t1.height, 
	t1.weight 
FROM \!"Big Class\!"  t1 
WHERE  (  (  ( t1.age IN  ( &age )  )  )  ) ;" );

// fill placeholder
Substitute Into( sql_str, "&age", "15" );

// execute query
dt_age = New SQL Query( Version( 130 ), Connection( "JMP" ), JMP Tables( cdt ), QueryName( "aged" || "_" || age ), CustomSQL( sql_str ) ) << Run;

[#7]

Great, that's really very useful! And since we've just created the database and I was the main actor of this creation, I've just made sure that no table name or variable name has parentheses or spaces, so it should simplify this generalisation.