|
If I remember right the SQLConnection I'm using in VB is basically ADO? I've been doing some reading and from what I've been finding people are saying that DSNs are "now slower than dirt", is this the case or just a case of them not being used properly? If they dropped intellisense support for ADO am I to believe that this is something that is going to be gone in the near future and replaced with something else? Again new to this side of things so excuse my lack of knowledge. Thanks again.
|
|
|
|
|
I think they are not using them properly.
|
|
|
|
|
I've got a newbie question, you can set up an ADO connection like you would in VB/C# you don't have to use a DSN right?
|
|
|
|
|
OK - every time you connect to a database - doesn't matter how it occurs, it takes time to establish the connection and verify the user's credentials. That's problem #1.
So use pooled connections or keep the connection open.
The second problem is that every time you create a new SQL statement for execution, the DBMS has to check the syntax and evaluate an execution plan for that statement.
Therefore if you have a 'WHERE' clause in the statement, use a prepared statement (SQLPrepare?? -haven't used ODBC for 10 years).
Of course you can get over the second problem by using SQL procedure or function calls.
|
|
|
|
|
MacRaider4 wrote: However our other programmer who is trying to get similar performance out of a MFC app is running into the problem of it being 4.5 seconds slower.
I doubt that your analysis is correct.
You are presuming that it is the code itself that is causing the performance problem. I would suspect otherwise.
But then there are many details missing from your problem description.
For example is the total run time 1 hour, so it is 4.5 seconds longer than 1 hour? Or it is .1 seconds in VB and thus 4.6 seconds in C++?
Are you testing a single attempt in both applications?
Are you testing on the same box and using the same database?
At what point to you time the speed?
How do you time the speed?
Are you using ODBC in VB?
Did you validate the time by running the tests for both applications multiple times?
|
|
|
|
|
I have changed my VB app to use the same DSN that the C++ app is using and it is still faster. The only thing that is being done is grabbing 4,500 or so records and populating a datagrid. Our C++ programmer is convinced it's something with the network, but if that was the case both should run equally as bad. Both are being tested on the same servers and have been run well over 50 times and the VB one wins out every time. Now being a VB programmer I know this really should not be the case as VB has more overhead than a MFC application thus should be running slower.
As far as timing goes, we have both apps getting time stamps before and after the process starts. I don't have the code infront of me, but it is basically startTime -> Open the connection and query the database -> return the results to a recordset -> close the connection, endTime.
Now I can't remember for sure if we open the connection then do the startTime or before, but I do know both are the same.
|
|
|
|
|
MacRaider4 wrote: I have changed my VB app to use the same DSN that the C++ app is using and it is still faster
By VB you mean in .Net? .Net uses connection pooling. You can modify the url to disable connection pooling.
You didn't mention what 4.5 seconds was relative to. However there is no way that establishing a connection on a lan should take 4.5 seconds unless something is wrong with the infrastructure.
MacRaider4 wrote: As far as timing goes, we have both apps getting time stamps before and after the process starts. I don't have the code infront of me, but it is basically startTime -> Open the connection and query the database -> return the results to a recordset -> close the connection, endTime.
If it is in fact C++ itself then you should be able to create a test app with a simple table structure and exactly reproduce the results. If you cannot do that then it would demonstrate that there is some other problem.
If you can do it then posting the exact code here, of the test app, for both languages would be helpful.
|
|
|
|
|
Hi all,
in my sdi application i m using non dockable toolbar.
but the doted edge displayed on the left side of toolbar.
please tell me how can i remove this.
thanks in advance.
|
|
|
|
|
|
can someone give me a pointer/example how to integrate C code in a MFC C++ project
the C code (and object code) is not seen by the MFC project.
the C++ and C work correctly independently
using MS Visual Studeo 10
thanks
steve
|
|
|
|
|
You may freely integrate C code into a MCF C++ application.
Could you please be more detailed and precise about your problem?
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]
|
|
|
|
|
Hi iain
on the C side: ive got a MS Visual Studio project in C. It uses a simple API
on the C++ side: ive got a MS Visual Studio project in C++ MFC that I use for the user GUI
I put the C header files in the C++ code using the extern "C" {...
there are two problems
1) I tried putting the C code in the VS MFC project... dosent work. obviously dosent compile the C code either
2) since the C code (and object code) is not there, there is a link error to the C API
C++ code call to the C xface "IRD_command_compile"
int cmd::reset_pin(void) {
sequence_number current_sequence_number;
int sequence_number = current_sequence_number.load_and_inc_Sequence_Number();
return IRD_command_compile(sequence_number,command_List_lib[RESET_PIN],NULL,NULL,&cmd_segment,EMM_payload_size);
}
thanks
steve
|
|
|
|
|
I'm Carlo, not Iain (neither Alfonso...). 
Stevefigo2 wrote: I put the C header files in the C++ code using the extern "C" {...
You shouldn't need this.
Stevefigo2 wrote: there are two problems
1) I tried putting the C code in the VS MFC project... dosent work. obviously dosent compile the C code either
2) since the C code (and object code) is not there, there is a link error to the C API
"Doesn't work" isn't much descriptive. What are the issues?
Stevefigo2 wrote: C++ code call to the C xface "IRD_command_compile"
What is this?
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]
|
|
|
|
|
Hi Carlo.. (sorry about that)
Ill try to be more descripive
1) I tried putting the C code in the VS MFC project using "add existing item" under the project properties... the VS MFC refuses to add the .c files. they should be displayed under the "Solution Explorer" tab, in the project name/"source files" folder. Since the .c files are not part of the project there is no compliation and no link
the "IRD_command_compile" is the C API call in the C++ code. something really simple.
thanks for the help
steve
|
|
|
|
|
I just made I test, adding a silly C file (and corrensponding header) to an existing MFC project. Visual Studio's 'add new item' worked fine (though I had to disable 'Precompiled Header' in project properties in order to make it compile).
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]
|
|
|
|
|
if your c code is just ansi c, you may not be having any problems while integrating.
If u can Dream... U can do it
|
|
|
|
|
If you have the source, just drop them in the project. I've done this with legacy projects many times. I actually prefer to rename them to .CPP files so I can take advantage of some of the things of C++.
In reference to your above comment, I'm mystified why it doesn't work. I don't believe VS 2010 has such a restriction, though there may be an obscure setting for the .C files. (I just remembered: you can force the .C files to be compiled as C++. Perhaps they are by default.)
|
|
|
|
|
|
Hello Friends
I have to copy BitmapData to Byte Array,So i am using memcpy but my bytre array is coming null.Is there any other option?
BitmapData bmpData;
bmpImage.LockBits(rect1, ImageLockModeRead, bmpImage.GetPixelFormat(),&bmpData);
int dataLen = bmpData.Stride * bmpData.Height;
BYTE * maskImageRGBData;
maskImageRGBData = new BYTE[dataLen];
memcpy(maskImageRGBData,bmpData.Scan0,dataLen);
Any Ideas Guys?
Regards
Yogesh
|
|
|
|
|
what you mean by "byte array coming as null" ? new BYTE[dataLen] returned null ?
If u can Dream... U can do it
|
|
|
|
|
After Memcpy byte Array maskIMageRGBData coming Null.
Any Ideas?
|
|
|
|
|
you code looks innocent to me. what is the size of image you are using ? try changing the data length in memcpy to arbitary small number(say just 3 bytes ) , so that you can find where the problem resides.
example from msdn
http://msdn.microsoft.com/en-us/library/ms536298(v=vs.85).aspx[^]
hopes this helps 
If u can Dream... U can do it
|
|
|
|
|
I tried by some small number but still after copying it is showing Null 
Regards
Yogesh
|
|
|
|
|
There's no need to find an alternative to memcpy, since that function works fine.
Are you sure that maskImageRGBData array size is correct (see, for instance, this MSDN code sample: "LockBits Method"[^])?
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]
|
|
|
|
|
Yes,cPillani.Array size is Corrrect tht is bmpData.Stride*bmpData.Height .but stil maskImageRGBData coming Null.
Regards
Yogesh
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
