Convert Sql Handle To Number

Discussion forum about all things Gupta, OpenText and the community.
Sunil

Convert Sql Handle To Number

Post by Sunil » 11 Feb 2014, 05:53

Dear All,

How To convert Sql Handle To Number and pass to another Applications using SalLoadApp('test1.exe',SalNumberToStrX(nSql,0))

Can anyone help me.

Regards.
Sunil

Igor Ivanovic
Site Admin
Site Admin
Croatia
Posts: 1462
Joined: 05 Mar 2017, 12:37
Location: Zagreb, Croatia

Re: Convert Sql Handle To Number

Post by Igor Ivanovic » 11 Feb 2014, 08:41

Hi,

You can use:

Code: Select all

   Sql Handle: hSql
   Number: nSql
Actions
   Set nSql = SalWindowHandleToNumber( hSql )
   Call  SalLoadApp('test1.exe',SalNumberToStrX(nSql,0))
Cheers
Igor Ivanovic
Image

Sunil

Re: Convert Sql Handle To Number

Post by Sunil » 11 Feb 2014, 11:48

Hi,

I had tried with your suggesion but returned 1, 2,3 like this,
purpose ,

app1.exe , connect hSql,hSql1,hSql2
app2.exe , connect hSql,hSql1,hSql2

app1.exe pass control to app2.exe on button say 'Switch To '
app2.exe reconnect hSql,hSql1,hSql2 which takes time.

i want to pass connected Sql handles in App1.exe to app2.exe so that app2.exe can use the same handles and don't have to fresh connect.

Regards.
Sunil

wardies
Great Britain
Posts: 86
Joined: 21 Mar 2017, 10:44
Location: UK

Re: Convert Sql Handle To Number

Post by wardies » 11 Feb 2014, 12:07

Sunil wrote:i want to pass connected Sql handles in App1.exe to app2.exe so that app2.exe can use the same handles and don't have to fresh connect.
This is not possible and you can prove to yourself why by creating an application that connects and then reports (e.g. in a message box) the SalWindowHandleToNumber() of the Sql Handle it obtained for the current connection.

Then compile the app and run three copies of the executable simultaneously so that you have three message boxes all popped up at once.

They will all report Sql Handle 1 is being used -- even if they're each connecting to different databases -- because the Sql Handles are unique only to the current process.

Sunil

Re: Convert Sql Handle To Number

Post by Sunil » 11 Feb 2014, 12:33

Hi,

in my case, i am using single database accessing by two application app1.exe and app2.exe . In that case, if uses same connected handles to another application.

Regards.
Sunil

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3392
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Convert Sql Handle To Number

Post by Dave Rabelink » 11 Feb 2014, 12:44

Is this second application (exe) a standalone application with it's own features?
Or are you trying to create a modular application where you split features between exe's?

A solution is to use apd's (dynalibs). For instance a reporting.apd which offers exported functions to create reports.
The SQL handle can be passed to an APD and reused. And if you have 2 separate exe's which both use the same reporting feature, you can reuse the apd's in both exe's. So 1 source, multiple reuses.

But the fact remains that you can not share sql handles between exe's. Only between an exe and an apd which is included.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Sunil

Re: Convert Sql Handle To Number

Post by Sunil » 11 Feb 2014, 13:25

Hi,

Right Dave, i am trying to develop modular application , or i can say split single application into two to reduce application invoke time and reduce application load.

but i don't understand why connected SQL handle can not be used in another application where all credentials are same.

Regards.
Sunil

wardies
Great Britain
Posts: 86
Joined: 21 Mar 2017, 10:44
Location: UK

Re: Convert Sql Handle To Number

Post by wardies » 11 Feb 2014, 15:57

Sunil wrote:but i don't understand why connected SQL handle can not be used in another application where all credentials are same.
Think about it from a security perspective then.

You create some Centura application that connects to secure database A.

I create another Centura application that tries to guess what Sql Handle other Centura processes are using and then issue SELECT statements on that Sql Handle to secretly steal data that I should not have access to because I don't have the required credentials.

This is definitely not allowed, nor is it desirable! If it was allowed, that would be a huge security hole.

Another way of thinking about it is by analogy to native file handles: if I have a process A that opens a file handle for reading, I can pass the numeric value of that file handle to process B but that does not imply that process B can read the contents of the file because the Operating System keeps a separate list of file handles open by each process A and B.

Sunil

Re: Convert Sql Handle To Number

Post by Sunil » 11 Feb 2014, 18:40

Hi,

I don't think any security issue , Gupta Technoglies allows pass parameters from one application to another through SalLoadApp('app1.exe',para1 para2....).

I think , Gupta Technical Team should now clarify on this, passing parameters through SalLoadApp is secure or Not.

Regards.
Sunil

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3392
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Convert Sql Handle To Number

Post by Dave Rabelink » 12 Feb 2014, 07:45

If you look at the value of an SqlHandle you will find it is just a integer which starts with 1 and increases by one. This value is maintained by the process, your single exe.
Another exe has it's own set of SqlHandles, also starting with 1 and increasing by one.
So a first connect in X.exe will have SqlHandle=1 and Y.exe on it's first connect will have SqlHandle=1.
They have the same value but they are different connections. Only this will hint you that SqlHandles are not uniquely system wide values, but are uniquely process wide values.
So passing this value from one process to another will not help.

But you really should look at why you want this. As you said, you want to create a modular application.
The way of creating multiple exe's is not a modular application.

The way to go is to use dynalibs. The reason having dynalibs IS to create modular applications by splitting it up in physical reusable parts at runtime level.

Pass the connected sqlhandle to a dynalib using it's exported functions and you can use it there.
Or even better, create a dynalib which manages all Sql connections centrally and from all your code spread over the exe and other apd's set and query those handles when needed.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Sunil

Re: Convert Sql Handle To Number

Post by Sunil » 12 Feb 2014, 07:53

Hi Dave,

Thanks for suggestion, i had never used dynalibs. One clarification still comes if application is very large say 23MB exe size , split in say two dynalibs , import in parent application , limit of outline constraint may come. In that how to come out when outline limit exceeded.

Regards,
Sunil

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3392
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Convert Sql Handle To Number

Post by Dave Rabelink » 12 Feb 2014, 10:17

A dynalib, when included in the apt, does not use outline space. Well, only for the exported items it does.
The complete code of the dynalib is hidden to the apt including the dynalib.

Compare it to a dll. The dll is build using sourcecode (eg a C++ source).
The dll itself, when used by TD will not include the sourcecode of the dll, but the dll-runtime file itself.

At compile time, only the exported items from the dynalib are compiled with the main application.
At runtime, the dynalib is only loaded (into memory/proces space) when the first exported item from the main application is called.

So assume you have now 1 apt which builds to a 100Mb executable.
This apt consists of 100 forms. Half of them are for reporting, the other half is specific business logic.
And lets assume that if you calculate the actual size of the forms and business logic and split them into reporting-functionality and business-logic-functionality it is
50Mb for reporting and 50Mb for business logic.

To split this up you can:

Create an apt with only the business logic/forms, without all the stuff for reporting.
Main.apt

Then create an apt having all the reporting forms and related stuff
Reporting.apt

Create exported items to be able to call the Reporting forms/stuff from outside.

Build Reporting.apt to Reporting.apd.
This will be an APD with size around 50Mb.

Then include in main.apt the dynalib Reporting.apd.
Call the needed exported functions from Reporting.apd.

Build main.apt to main.exe which will result in about a 50Mb executable.

You will have then:
Main.exe
Reporting.apd

When you start the exe, the apd is not (yet) loaded into memory. So your initial footprint has decreased from 100 Mb to 50Mb.
Only when the user executes functionality which will call Reporting.apd, the dynalib is loaded and executes the functionality.
But when the user does not use it, the apd will not be loaded at all.

This way, you decrease compile time, decrease outline space, decrease loading times at startup and decrease memory footprint of the entire application
when parts are not used.

(PS, the size examples are not completely correct, there is some overhead in exe/apd sizes)


Gupta has introduced dynalibs just for this purpose. To create modular applications without having to create separate exe's having all those issues like
passing data between them etc etc.
So if you have issues with compile times, outline-limitations, large exe's, reusability, functional encapsulation, memory usage, deployment etc etc, dynalibs are an answer.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

Sunil

Re: Convert Sql Handle To Number

Post by Sunil » 12 Feb 2014, 10:54

Thanks Dave.

Great explanation How To Use APD's in Gupta.

one clarification i need from you, e.g .,

app1.apd
app2.apd
app3.apd

main.exe

if user called any module say frm1 which is available in app1.apd , okay , autoload in memory and use.
if user called any module say frm2 which is available in app3.apd , okay, autoload in memory, use , here question what happened with app1.apd will this offload from memory or reside in memory until exit from main.exe.

Regards.
Sunil

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3392
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: Convert Sql Handle To Number

Post by Dave Rabelink » 12 Feb 2014, 12:06

Once a dynalib is loaded into memory (so is called at least once) it will be kept loaded.
There is no "unload" dynalib feature (by code or internally).

So, the architecture of your complete application is important.
In fact, for new projects, you really need to think "architecture" before implementing and design it all to be functional and technical modular.
(but normally this would be done in the design of the system, which we all do before starting to code, ahum.)

For instance:

Say you have two main features: reporting and database maintenance (table editors).

You split this up in:

Main.exe
Reporting.apd
TableEdit.apd

The main application needs features from TableEdit.apd and calls an exported function TableMainEditor( ) which is exported by TableEdit.apd.
The main application also needs to start a Reporting feature and calls an exported function StartReporting( ) which is exported by Reporting.apd

But Reporting.apd also needs a table edit feature so it has TableEdit.apd included and calls TableReportEditor( ) from TableEdit.apd

Here a design flaw: when creating an exported function StartTableReportEditor( ) on Reporting.apd which in turn calls TableEdit.apd you get:

Main.exe -> Calls StartTableReportEditor from Reporting.apd
in turn reporting.apd calls TableReportEditor( ) from TableEdit.apd.

This results in having TableEdit.apd loaded in memory and also Reporting.apd.
This can be avoided when Main.exe calls TableReportEditor( ) from TableEdit.apd directly (without the Reporting.apd in between).

So, you are able to nest dynalibs.

Also to remember:

Main.exe -> TableEdit.apd
Main.exe -> Reporting.apd
Reporting.apd -> TableEdit.apd

TableEdit.apd is loaded once. So when main.exe uses TableEdit.apd and Reporting.apd also uses TableEdit.apd, this dynalib is loaded initially by the first calling side
and furtheron any other calls from other locations will use the same loaded dynalib.

This way you can create a central dynalib to store global data which can be reused by all other dynalibs in the application.

So for instance, you have a list of products loaded from database.
It will be used by Main.exe, Reporting.apd and TableEdit.apd.

It is not efficient to load this list every time when needed in those locations.

Create a dynalib which stores such lists, for instance a dynalib named TableData.apd

When Main.exe needs the list, it calls an exported function GetProductList( ) from TableData.apd.
In TableData you load the list from the database and keep the data globally as UDV list in the dynalib.

Now when Reporting.apd needs the same list, it then calls the same exported function GetProductList( ) from TableData.apd.
But main.exe has already loaded the list, so TableData.apd has this list already present.
The dynalib will then return the already stored list to anyone asking for it without going to the database.

This improves performance. So shared data can be stored in specific dynalibs which can be queried from wherever.
(this works because a dynalib is only loaded once and you reuse the state of the dynalib between all dynalibs in the application.
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

User avatar
markus.essmayr
Austria
Posts: 892
Joined: 06 Mar 2017, 06:07
Location: Austria

Re: Convert Sql Handle To Number

Post by markus.essmayr » 14 Feb 2014, 08:12

Hello,

just a few words on passing Sql Handles to another application.

Consider you declared the following array in your application:

Code: Select all

String: myStrings[*]
Now you set some entries (lets say manually using a Form Window).

Code: Select all

Set myStrings[0] = "String number one"
Set myStrings[1] = "This is another string"
Set myStrings[2] = "And now the last string"
Now, while your application is running, you launch it a second time and pass index 1 to it.
The myStrings array will be empty at launch time and even you passed index 1, you won't get "This is another string" from the array.

It's the same with the Sql Handles.
They are managed on a per-process level so it's absolutely impossible to reuse it in another process.

Hope this helps a bit to understand it!
Max
Markus Eßmayr
teamdeveloper@t-mx.com

Return to “General Discussion”

Who is online

Users browsing this forum: [Ccbot] and 3 guests