GetVariableValueFromName

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Does exists a function GetVariableValueFromName (o something similar) to get
a variable value from a string that contains variable name ?
Example:
Dim Target as string
Dim Source as string = "aaa"
Dim sSourceName as string = "Source" 'This is the name of the variable
Target = GetVariableValueFromName(sSourceName)
' -- now Target has the value "aaa"

Thanks

Piermaria
 
You could likely use System.Reflection.

Also, having the whole scenario could help to raise a whole new solution
than using "indirection" (i.e. having a variable that contains the name of
the variable you want to access).

Patrice
 
First, thanks a lot for your suggestion.
I try to explain better my problem:

I need to convert in vb.net (asp.net) Gupta SqlWindows application. This
application uses some thousand of Sql statements stored in an external file.
In SqlWindows i have this function :

SqlPrepareAndExecute("select field1,field2, field3 from TABLE1, TABLE2, ...
where .... into :vh1,:vh2,:vh3")

So i can pass to SqlPrepareAndExecute a string (read from external file)
with the Sql Command (with bind and into variables written as substring
inside the string). In the example vh1,vh2,vh3 are variables declared in the
caller function of SqlPrepareAndExecute. When SqlPrepareAnd Execute finish
vh1,vh2 and vh3 contain the fetch values retrieved by the select.

Now in vb.net i dont't want to change all the Sql statements. I think to
build a function SqlPrepareAndExecute with the existing string parameter and
another parameter (a object array) for receiving fetch value. But after
execution i have the problem to dinamically assign the value in object array
to the real into variables (in the example vh1,vh2,vh3).

Thanks in advance for suggestions and help.

Piermaria
 
AFAIK you'll have anyway to drop (perhaps programmatically) the into clause
that will not be recognized by the DBMS.

I would do something like :

SqlPrepareAndExecute(Statement,vh1,vh2,vh3)

The routine will just perform the select and will affect the first column to
vh1 (without any concern with the name just using the position), second to
vh2, etc allowing to transport the binding outside of the SQL Statement....

If not acceptable, have a look at System.Reflection that will allow what you
need but I would really drop the tight coupling between SQL code and
application variables...

Also I would check how Gupata SqlWindows handles multiple rows ? Does it
have some kind of mechanism for this ?

Good luck.

Patrice

--
 
Piermaria said:
Does exists a function GetVariableValueFromName (o something similar) to get
a variable value from a string that contains variable name ?
Example:
Dim Target as string
Dim Source as string = "aaa"
Dim sSourceName as string = "Source" 'This is the name of the variable
Target = GetVariableValueFromName(sSourceName)
' -- now Target has the value "aaa"
Click to expand...

You can do this for static and member variables using reflection
(Type.GetField to get a FieldInfo, then FieldInfo.GetValue to get the
value) but I find that in most situations where this is requested, a
simple map from name to value would be a better solution.
 
Thanks for your answer.
I agree to cut the into clause of the sql statement.
But i don't understand how build the SqlPrepareAndExecute function.
It must have a variable number of paramters vh1,vh2,vh3,vh4, ... depending
from the number of fields extracting by the select. I could have a ParamArray
paramater but in .Net this is only byval and not byref. What do you think
about this ?
About multiple rows: for now we can ignore this problem because most of all
the select return only one row.

Piermaria
 
In VB.NET you can easily have multiple parameters using the ParamArray
keyword...

You could also create explicitely multiple overloads depending on the
easiest way (i you have a low different number of parameters and a unique
combination of types, it would give type safety as a benefit). You can
always start by the quick "ParamArray" way and move on at a later time once
you have are more confident with the whole design...

Patrice

--
 
Hi Piermaria,

There are many problems in supporting SQLWindows bind and into variables
(and expressions). We have developed our PPJ Framework as part our Porting
Project effort to port SQLWindows applications to .NET (C#) and we support
most Sql.* statements including bind and into variables and expressions. See
www.iceteagroup.com for more info.

The major problems are: scope, bind expressions, and bind controls. In
SQLWindows you can have sql statements like this: SqlPrepareAndExecute(h,
"select name from company into :m_company[getNext()].name"). The m_company
array can exist in any scope since your code might have called
SqlVarSetup(h) anywhere. The getNext() function (or a nIndex variable) can
also live anywhere, including a form, the global scope, or even
locals/parameters (which are impossible to access using reflection).
Additionally the bind variable can also be a control or a table column. To
make matter a bit more complicated, as you know, the scope can be changed
while fetching rows but calling SqlVarSetup() before the next
SqlFetchNext(). Sql statements can also be built dynamically by the
application (which is the most common case) and therefore it's very hard to
detect the variables involved. In order to support SQLWindows original code
we use a mini interpreter with a lot of reflection optimization to preserve
performance. It really required a lot of work.

The only other alternative is to re-engineer your application and use
ADO.NET parameters. Another problem you might face is that ADO.NET throws
exceptions (not normalized either, but specific to the database) while your
SQLWindows application uses When SQLError constructs which have no equal in
the OOP world. We replicated them either as try/catch blocks (which changes
the logic of the application) or as delegate error handlers (which preserves
the original logic but makes the code look a bit awkward).
 
Gianluca,
could you contact me at: (e-mail address removed) (cu NO and SPAM) in
private form to talk about your product ?

Thanks
Piermaria

GP said:
Hi Piermaria,

There are many problems in supporting SQLWindows bind and into variables
(and expressions). We have developed our PPJ Framework as part our Porting
Project effort to port SQLWindows applications to .NET (C#) and we support
most Sql.* statements including bind and into variables and expressions. See
www.iceteagroup.com for more info.

The major problems are: scope, bind expressions, and bind controls. In
SQLWindows you can have sql statements like this: SqlPrepareAndExecute(h,
"select name from company into :m_company[getNext()].name"). The m_company
array can exist in any scope since your code might have called
SqlVarSetup(h) anywhere. The getNext() function (or a nIndex variable) can
also live anywhere, including a form, the global scope, or even
locals/parameters (which are impossible to access using reflection).
Additionally the bind variable can also be a control or a table column. To
make matter a bit more complicated, as you know, the scope can be changed
while fetching rows but calling SqlVarSetup() before the next
SqlFetchNext(). Sql statements can also be built dynamically by the
application (which is the most common case) and therefore it's very hard to
detect the variables involved. In order to support SQLWindows original code
we use a mini interpreter with a lot of reflection optimization to preserve
performance. It really required a lot of work.

The only other alternative is to re-engineer your application and use
ADO.NET parameters. Another problem you might face is that ADO.NET throws
exceptions (not normalized either, but specific to the database) while your
SQLWindows application uses When SQLError constructs which have no equal in
the OOP world. We replicated them either as try/catch blocks (which changes
the logic of the application) or as delegate error handlers (which preserves
the original logic but makes the code look a bit awkward).

--
Best regards,
Gianluca Pivato
--
Ice Tea Group, LLC
www.iceteagroup.com


Piermaria said:
Thanks for your answer.
I agree to cut the into clause of the sql statement.
But i don't understand how build the SqlPrepareAndExecute function.
It must have a variable number of paramters vh1,vh2,vh3,vh4, ... depending
from the number of fields extracting by the select. I could have a ParamArray
paramater but in .Net this is only byval and not byref. What do you think
about this ?
About multiple rows: for now we can ignore this problem because most of all
the select return only one row.

Piermaria
Click to expand...
Click to expand...
 
Back
Top