B
Brandon
We are running out of VM in our main application, and among other things, I
am considering how we might break functionalities across groups of native
dll's that have to load for those functionalities. An obvious break line
involves sqlmobile (3.x). I threw together a quick proof of concept for
basically creating a database engine process that would perform all sqlmobile
access, with a TCP interface for issuing commands and getting results wrapped
in XML (we already do something similar in a process that performs all of our
replication - conceivably, this process would grow up to be a sqlmobile
engine that handles both queries and replication). I know that there may be
something we can do that will be more efficient than XML, but our result sets
are generally small - probably the biggest one is 18 rows by about 30
columns. Hopefully an added benefit would be that we might even be able to
put together an algorithm for caching a few query plans...we have been unable
to do this for some time, due to VM constraints.
I can't imagine that this is as avenue that has not been explored, and am
just wondering if anyone has any comments on the approach - is this a bad
idea? It seems like if this were a viable option, that it would already
exist out there somewhere, probably even provided by Microsoft. Maybe they
were just afraid people would try to use it in a more robust way than it was
intended...?
am considering how we might break functionalities across groups of native
dll's that have to load for those functionalities. An obvious break line
involves sqlmobile (3.x). I threw together a quick proof of concept for
basically creating a database engine process that would perform all sqlmobile
access, with a TCP interface for issuing commands and getting results wrapped
in XML (we already do something similar in a process that performs all of our
replication - conceivably, this process would grow up to be a sqlmobile
engine that handles both queries and replication). I know that there may be
something we can do that will be more efficient than XML, but our result sets
are generally small - probably the biggest one is 18 rows by about 30
columns. Hopefully an added benefit would be that we might even be able to
put together an algorithm for caching a few query plans...we have been unable
to do this for some time, due to VM constraints.
I can't imagine that this is as avenue that has not been explored, and am
just wondering if anyone has any comments on the approach - is this a bad
idea? It seems like if this were a viable option, that it would already
exist out there somewhere, probably even provided by Microsoft. Maybe they
were just afraid people would try to use it in a more robust way than it was
intended...?