|
I'm ready to start my SQL Server part of my program, but can't decide which version to use.
There is the native SQL Server sqlncli.h which I think uses SQLOLEDB. Sounds like the way to go, but some caveats exist. If the customer does not have the client installed, I have to download the client and install it for them.
I was looking for something more portable.
There is a sqloledb.h that comes up when I add the include, seems builtin, comes from microsoft sdk's in program files.
I don't want to start writing code, and have to start again.
What do you think?
|
|
|
|
|
This isn't really a coding question (has nothing to do with C/C++/MFC), it's more of a design or tools question, so another forum may be more appropriate.
With that said, I would compare databases available and pick one that has all the features your customer needs, don't worry as much about installation, worry about meeting the requirements (installation can be dealt with documentation). For example, some databases are going to be more appropriate for certain applications (i.e. maximum database size, type of data stored, types of queries, platforms supported, interfaces, security), so I would start by compiling a list of requirements, then do a comparison of databases available and pick whatever suits the overall application best.
|
|
|
|
|
I apologize for not phrasing the question right.
I already have an established database using Microsoft SQL Server 2008 Express Edition RTM 10.500.1601. that was written for a asp.net application.
Now I want to connect to the same database server using c++.
|
|
|
|
|
Oh, I see.. sorry... I'd choose something that doesn't require installation of another component. Supporting interactions with yet another "middle-ware" when you don't have to can become a pain.
|
|
|
|
|
[Here] is an Example of "Connecting To SQL Server Using C++ ODBC".
|
|
|
|
|
Cool Thanks,
It's hard too find stuff on that, I've been looking for awhile. I'll going to try SQLOLEDB first and see how that works. I just needed a reference to get started.
|
|
|
|
|
[SQL OleDbConnection.ConnectionString Property]
void CreateOleDbConnection()
{
String* myConnString = S"Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=Northwind;Integrated Security=SSPI;";
OleDbConnection* myConnection = new OleDbConnection(myConnString);
myConnection->Open();
MessageBox::Show(String::Format( S"ServerVersion: {0}\nDataSource: {1}", myConnection->ServerVersion, myConnection->DataSource ));
myConnection->Close();
}
|
|
|
|
|
Thanks for the info. I ended up using SQLNCLI10, the native connector that comes with SQL Server.
What a pain in the ***, well at least till I figure it out. So I can initialize and connect, get a rowset back, just trying figure out how to process the rowset data.
|
|
|
|
|
Hi,
i have a console project. then an console exe.
i want in another project(dlg project), to execute this console exe. i execute it with calling ShellExecute() function.
now, i want to send some messages to this exe.(to send message from dlg to console) how do i do it? i don't have any hWnd of console exe in dlg project!
please help me.
Zo.Naderi-Iran
|
|
|
|
|
Console projects do not have the capability to interact in this way, as they do not have message queues.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
You are trying to do the impossible here, as the other poster stated. But you can pass data between proceses outside of the windows messaging system. Check out interproces communication in the MSDN. Windows hooks are one method I have used a lot.
==============================
Nothing to say.
|
|
|
|
|
A console application does not have a message pump and so cannot accept a windows message. However, you can still communicate with a console application with the help of several IPC mechanisms available (for example - sockets[^], pipes[^], etc.,)
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
As already (correctly) stated you can't use Windows messages to communicate with the console child process. Have a look at an alternative (to the proposed ones) way: "How to spawn console processes with redirected standard handles"[^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Windows offers a number of ways for two processes to communicate. See Here[^] Once you decide on a method, you can search for a reference implementation of that method on Code Project to on the net.
|
|
|
|
|
Hi,
For some reason I have been seeing this question alot... and the adequate responses. Although it is correct that console applications initially do not have a message queue... the first time a win32k.sys/GDI syscall greater or equal to 0x1000 is invoked... the windows kernel increases the thread stack-size and invokes KiConvertToGuiThread which will convert the console thread into a GUI thread with a message queue.
How do you 'invoke a system call above 0x1000' ?
WIN32K.SYS System Call Table[^]
As you can see in that table... the first GDI system call NtGdiAbortDoc is at index 0x1000. Because we know that the GetMessage function[^] results in a call to NtUserGetMessage and the DispatchMessage function[^] results in a call to NtUserDispatchMessage. We can infer that by simply creating a message loop... we will have in-fact promoted the thread into a GUI thread.
In other words... by simply attempting to pump the message queue... the thread is given one.
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
So what do you have now? Now you have a console process with a thread containing a message queue that has no window HANDLE so cannot recieve window messages. Is this the end of the road?
No, window messages are not the only type of message. You can still use the PostThreadMessage function[^] to post thread messages to the console.
Step 1: Create two console applications... Sender and Reciever.
Step 2: In the reciever begin an infinite message pump (console thread will be promoted to gui thread by the subsystem)
Step 3: In the sender call CreateProcess with the CREATE_NEW_CONSOLE flag that creates the reciever process. (otherwise messages will appear in senders console!)
Step 4: Using the PROCESS_INFORMATION.dwThreadId begin posting messages with PostThreadMessage to reciever from sender.
Best Wishes,
-David Delaune
|
|
|
|
|
Nice.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
How do you create/register the message handler func?
==============================
Nothing to say.
|
|
|
|
|
Hi,
What message handler function are you referring to? The GetMessage function[^] is exported from the user32 library.
Best Wishes,
-David Delaune
|
|
|
|
|
#include <windows.h>
#include <stdlib.h>
#include <iostream>
using namespace std;
#pragma comment(lib, "user32")
int main(int argc, char *argv[], char *envp[])
{
DWORD idThread;
MSG Msg;
if (argc == 2)
{
idThread = atoi(argv[1]);
if (!PostThreadMessage(idThread, WM_COMMAND, (WPARAM)0, (LPARAM)0))
cout << GetLastError() << " PostThreadMessage error\n";
return 0;
}
cout << GetCurrentThreadId() << " thread id\n";
while (GetMessage(&Msg, NULL, 0, WM_USER))
{
if (Msg.message == WM_COMMAND)
cout << "WM_COMMAND\n";
else
cout << "Message: " << Msg.message << endl;
}
return 0;
}
|
|
|
|
|
|
If you have access to the console app source code, and you go to the trouble of adding the message pump, you may as well add code to create a message-only window, no?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi Richard,
Richard Andrew x64 wrote: you may as well add code to create a message-only window, no?
It doesn't really matter to me how you decide to implement IPC between console applications. As Rajesh suggested you could use sockets, pipes or as Carlo Pallini suggested you could use STDIN/STDOUT/STDERR or as you suggested a hidden window or the option I have suggested; PostThreadMessage. It is great to have so many options put on the table.
Best Wishes,
-David Delaune
|
|
|
|
|
Yep, definitely not impossible (people get too used to the framework doing magic)... I think it's just a bit of a hassle more than anything else. Good job pointing this out!
|
|
|
|
|
It is not possible but you can cheat. Reverse engineer it.
Create a Windows app (win32 or MFC) and redirect messages to a console window.
But once you add a window, your app will no longer be a console app.
So it is still not possible.
See [this].
More reversed console apps [here] and [here].
|
|
|
|
|
Here is another example, to go along with Carlos'.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|