Thank you for your kindly advice.
But my vaccine 365 security reject it as a virus. But www.virustotal.com doesn't report it as a virus. I also have no clue on it, maybe the vaccine detects the approach to the registry by debug mode built service.
Now I'm using Error log file and monitor its action.
Please check this function and give me your precious advice.
sQuery = "select * from my_settings";
If I set this value like this, SQL query will be succeed, but only using sQuery normally will be failed. Simple query such as "select * from my_dbversion" will be succeed but large data querying will be failed. I don't know the clue.
Just noting that in general a windows service would not be used to "manage" a database.
A database might be a windows service (or more than one service.)
A management API would exist on one of those servers.
Then an application, not service, would use that API and present a interface, like a GUI, to a user. The interface could also be a command line console.
A service API that would support the above would support the following
1- A definition of a protocol, such as Rest or more generally http
2- Commands that are sent via the protocol and responses to those commands.
3- The API protocol would be a LAYER on top of the actual management code.
3a - Supporting 3 one should probably add logging.
4- Management layer.
At best from your code it looks something like 3. I suggest you look into learning how to use a logging API.
Additionally there are other aspects involved with getting a windows service to run, and those have nothing to do with the actual database problem. For example
A- Starting/stopping the service
B- Running with the correct user
Member 11967800 wrote:
If I give a static command such as "select * from my_settings" instead of sQuery.c_str(), it operated properly, but it doesn't act when it receives a dynamic params.
That doesn't have anything to do with windows service. It has to do with how you implemented the code. At best this looks like 4 above and you should get it that to work BEFORE you attempt to do anything else.
In addition to what Jochen said, sometimes looking at the disassembly is helpful.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
First of all: Casting happens implicitly so you don't need to cast in this scenario.
Secondly: These types that you are specifying in non-standard types, so uint32_t could be defined as anything which will give you an incorrect result.
Thirdly: How to you check what the result is? Though debugging or though a print statement? The print statement could be wrong.
Fouth: Know your platform you writing the code for (its limitations and the standard it is using). Not necessarily that the pic32 uses the specific c standard which you are looking at.
"Program testing can be used to show the presence of bugs, but never to show their absence."