part of still hanging in the DA3 era is the fact that DA3 used to have a statement name
i found that extremely handy to have multiple sql statements for the same connection so you could have different results without the need of using parameters, for example a product name that is in another language, all handled by switching statement names at the server level
when the schema builder got ported to .net we lost that statement name property (conflict in .net?)
we worked around it by copying the statement name in the connection name and at runtime we put it back into the statement name property which still exists … so our code still runs using statement names…
since da3 is deprecated and there will be a day that this beautifull mechanism will cease to exist, what is an alternative way to archive this?
using connection name isn’t a real option cause when i have 10 tables with 10 statements, i would need 100 connections
so is there a way around so i can get rid of DA3 and still use this flexibility…
tia,
Marc
one from possible workarounds can be using personal schema for each region/language.
i.e. you can load %language%.daSchema in run-time: for english - it will be english.daSchema, for french - french.daSchema, etc.
Note: if you save .daSchema in binary format (pfBinary), it will be loaded more faster in comparing with pfXML format
language was an example… i have about 20 statements for 1 table, handling different result sets in different languages… so that won’t do the trick…
is it possible to solve it with where?
for example, your sql can be like
select ...
from ...
where
((:Param1 = 1) and (... )) or //USA
((:Param1 = 2) and (... )) or //France
.... //something else
it’s more complex than using parameters, cause lets say i need 10 params then they always need to be present…
but we do things like not joining a heavy part of the query (a light version of the table sort of speak) so an initial selection gives a fast result as where going into detail pulls a more complex and heavy query
an alternative road is to fiddle around with the strong typed interfaces, as long as the dataset has the same fields you can interchange them using a kinda proxy but that is way more complicated to maintain cause then you end up with different tables that need to be in sync…
so i guess statement name will not be resurrected?
you are right.
how about dynamic where? it will give better performance in comparing with my previous example
won’t work:
select * from product join englishproductname join stock join sales where blablabla
select product., englishproductname., fakefieldscauseidontneedstock from product join englishproductname join stock join sales where blablabla
select product.onlythenecessairyfields, productfakefields, fakeneglishfields, fakestock from product where blablabla
do the same for french…
and all other combo’s
fact is that you still have the same base product DA table that you can use everywhere, only 1 interface to remember etc etc… it is always the same class that gets passed around only the actual data is different…
if you’de see it it would make more sence 
you can declare as many statements as you want in the schema, but i have no way of selecting the one i want… so right now it also has no meaning to be able to create 10 statements if you only have 1 connection not?
we have such logic in
function TDASchema.FindDatasetStatement(
const aConnection: IDAConnection;
aDataset: TDADataset;
aStatementName: string;
aConnectionType:String): TDAStatement;
:
- detect statement by connection name (
aConnection.Name) - detect statement by connection Type (
aConnectionType) - detect statement by connection Type (
aConnection.ConnectionType) - detect statement if it has
Default(aDataset.Statements[i].Default= True) - detect statement if it has
stAutoSQL(aDataset.Statements[i].StatementType = stAutoSQL) - detect statement for default connection (
ConnectionManager.GetDefaultConnectionName)
so you can use Statement.Connection as placeholder for Statement.Name .
if you patch TDAStatement as
property Name: string read fConnection write fConnection;
it will work as before
well that’s exactly my point… the code is there, so why not surface the possibility again?
when the schema DM is loaded we now iterate trough all datatables and copy connection to statement, from that point on it works as we expect…
i can’t remember why it was pulled…
and i’de like to keep the patched units as small as possible
if you would introduce a compile directive or a global setting that says ‘treat connection as statement’ it would we solved in the stock code?
oh does this mean it’s under review?
we can add a new define for this
I still use the old schema builder with RO 9.6, no problem at all, and for this and another features not present in the new schema builder don’t plan to change in a near future, only if be forced too (and will be a big problem for me).
can you remind to me about what features you mention here?
Sure.
Lacks of:
*Schema Validation and all the stuff associated like showing the error pointed (crucial for me)
*Data Dictionary (crucial for me)
*Business rules only in java script (not pascal script supported)
Pascal script rules is FAR AWAY most simple to code because can use FIELDS NAMES in place, and is PASCAL, you know…
Javascript business rules are SLOW compared to pascal script.
*The layout in general is unconfortable than the previous schema modeler. In general in schema modeler you are seeing almost all the information without the need of double click an item to edit. Example : fields needs to double click to edit.
- Performance. Is a lot slower than old schema modeler.
- Connection definition also is very uncomfortable than predecesor.
That are the reason I pray old schema modeler remains compatible for ever.
HTH.
thx!
i agree here, old one was better for me to…
this especially:
In general in schema modeler you are seeing almost all the information without the need of double click an item to edit
Hello.
Could you send to support@ a sample of your schema with multiple named statements (for testing purposes). You can leave there just one table and even rename it, if its name / statements contain any sensitive info.
Thanks in advance
sure
but i think Evgeny has it already - if not i’ll resend to support@ ?
Please resend it (just in case)