I have a firemonkey app, running on Android. I have a StoredProc component that calls a simple stored proc with 5 input parameters. It is used for logging. On my KBM side, I am connected to SQL server using UNIDAC. All seems well, but this stored proc gets called twice for some reason and ends up leaving 2 entries instead of one. One with empty params, then the stored proc with my passed params. Leaves 2 log entries, the first is empty. Ive stepped though my code to insure the proc is not being called anywhere else, only one thread, no recursiveness. I even wrote a stand alone app to test using UNIDAC and it works fine.. But when i use KBMMW, I get two hits to the stored procedure. There are 2 of my stored procs that have this same behavior. The only difference with these 2 and the rest is that these 2 procs that dont work don’t have have any output parameters. Ive tried everything I know to make it work. Im pulling my hair out… Any thoughts?
(handled by email)
Usually the thing to look for is what setting AutoFieldDefsOnOpen is set to. If it is mwafoAlways then it will make two calls on each tier. So if you have a clientstoredproc connected to a serverstoredproc in an application server, you will end up in the client making the request twice to the application server, and for each call the server stored proc will make two calls to the database.
The first call is to fetch definitions, the second is to fetch actual data.
Some databases (and 3rdparty db connectors) understands the difference and thus only executes enough for the first call to be able to provide the definitions (fields/parameters) but without needing to execute the inner features of the stored proc, until when it is actually called (2nd call) or opened. But others are more dumb and actually makes a full execution/open each time.
For that reason it is possible to use never, once and withdata. Never require you to predefine the parameters and fielddefs on the query/stored proc. Then those will be used. once will make the 2 calls, but only once. After the definitions are known, it will not ask for it again. withdata will only make the definition available late in the process, namely when data has been returned.
If this does not solve the issue, then it must be something else, and in that case there is no way around actually debugging the issue, for example by placing a break point in the PerformRefreshDefinitions method of the used database adapter. Then track back and check what is triggering the call.