Tweet
Hi
I'm currently working with 5 application server, each running an isapi extension that has about 80 database connections to a single database server. Which works great btw but there might be some limits one day as the load keeps growing.
For the new version of our software, I was thinking of creating a kind of DataAccesLayer component and use the n-tier approach. This could be an isapi as well and would 'manually pool' the requests for the different database (eg in my case reducing the 400 database handles that are opened all together, to 80).The isapi's on the app servers would have to use wininet to call this 'dal isa'.
The problem then will be how to pass the recordsets from the DAL to the calling isa (the 'client'). I cannot return a recordset object as .net does although this form of remoting is (of course) also just a pre-defined and (probably) efficient way of transferring tcp packets into a local recordset instance. So, this should be possible in PB, no?
Just for the record: I do not want to work with ADO, variants and the like since I'm doing this to create more efficiency and speed, not less (even if I'm wrong, just humor me).
So my questions are these
- I would need a very fast way to read a recordset. Is there a way to get a handle directly to the memory?
- can anybody get me started on how an odbc recordset is build up in memory? How could I parse this?
- I would also need to create a recordset 'object' at the client app so I can fill the incoming data into it and loop through it's records. I'm currently a happy user of SQL Tools and have written most of my code with it, so it would be great if I could keep (most of) my code.
One could to do this by creating an xml string from the recordset, passing it back to the client and using this xml struct as a kind of recordset, but I was wondering if there was a more direct way without the extra parsing.
Or maybe I'm asking to much. As I understand it momentarily, SQL tools uses the ODBC api which calls the Odbccr32.dll (from MS) which handled the connection to the driver and the cursors. Eg, this dll is holding the actual memory and there's no way to reach the actual memory location. But I'm not sure if I understand it correctly.
Eg, this is a lot of new stuff to me so if anybody can get me started, much appreciated. I don't know if it would be possible but it would be a great idea at least (imo).
Regards
Jeroen
I'm currently working with 5 application server, each running an isapi extension that has about 80 database connections to a single database server. Which works great btw but there might be some limits one day as the load keeps growing.
For the new version of our software, I was thinking of creating a kind of DataAccesLayer component and use the n-tier approach. This could be an isapi as well and would 'manually pool' the requests for the different database (eg in my case reducing the 400 database handles that are opened all together, to 80).The isapi's on the app servers would have to use wininet to call this 'dal isa'.
The problem then will be how to pass the recordsets from the DAL to the calling isa (the 'client'). I cannot return a recordset object as .net does although this form of remoting is (of course) also just a pre-defined and (probably) efficient way of transferring tcp packets into a local recordset instance. So, this should be possible in PB, no?
Just for the record: I do not want to work with ADO, variants and the like since I'm doing this to create more efficiency and speed, not less (even if I'm wrong, just humor me).
So my questions are these
- I would need a very fast way to read a recordset. Is there a way to get a handle directly to the memory?
- can anybody get me started on how an odbc recordset is build up in memory? How could I parse this?
- I would also need to create a recordset 'object' at the client app so I can fill the incoming data into it and loop through it's records. I'm currently a happy user of SQL Tools and have written most of my code with it, so it would be great if I could keep (most of) my code.
One could to do this by creating an xml string from the recordset, passing it back to the client and using this xml struct as a kind of recordset, but I was wondering if there was a more direct way without the extra parsing.
Or maybe I'm asking to much. As I understand it momentarily, SQL tools uses the ODBC api which calls the Odbccr32.dll (from MS) which handled the connection to the driver and the cursors. Eg, this dll is holding the actual memory and there's no way to reach the actual memory location. But I'm not sure if I understand it correctly.
Eg, this is a lot of new stuff to me so if anybody can get me started, much appreciated. I don't know if it would be possible but it would be a great idea at least (imo).
Regards
Jeroen
Comment