Hello,

I Was Wondering If Anybody Would Know Why A Program Would Retrieve Information From A MySQL Database Faster When Ran From VB, Then When It Was Compiled. Takes About 5 Times As Long.

: Hello,
:
: I Was Wondering If Anybody Would Know Why A Program Would Retrieve Information From A MySQL Database Faster When Ran From VB, Then When It Was Compiled. Takes About 5 Times As Long.
:

This is interesting!

You need to narrow down where the slowup is. Is it in login? Or actual data access?

Is the compiled program run on the same machine? Did you time it using the same machine that the MySQL database is on?

Can you write a very simple test program that logs in, grabs a bunch of data, and logs off? Try that compiled and development mode, and let us
know.

This is very interesting...




Melissa

: : Hello,
: :
: : I Was Wondering If Anybody Would Know Why A Program Would Retrieve Information From A MySQL Database Faster When Ran From VB, Then When It Was Compiled. Takes About 5 Times As Long.
: :
:
: This is interesting!
:
: You need to narrow down where the slowup is. Is it in login? Or actual data access?
:
: Is the compiled program run on the same machine? Did you time it using the same machine that the MySQL database is on?
:
: Can you write a very simple test program that logs in, grabs a bunch of data, and logs off? Try that compiled and development mode, and let us
: know.
:
: This is very interesting...
:
:
:
:
: Melissa
:
:

Here's The Setup:

Linux Server: Hosting The Database
Windows 2003 Server: Hosting The Program For Multiple Users
Local Win XP Pro Machine: Machine Used To Create And Compile .exe

Its Slow When Getting Information From The Database (Which Login Info Is Stored As Well). I've Figured Out That Its Not When Its Compiled That Its Slower, Its When It Gets Put On The 2003 Server, Which Means Its Not Anything To Do With The Program Itself, Its A Networking Issue (At Least I Think So). When Ran Locally, It Could Connect Directly To The Database Server, But When Ran Off The Domain, It Would Have To Go Through Both Servers. Next Step Is For Me To Run It Directly From The Domain, And See If Its As Fast As Running It Locally. If This Isnt The Case, Then I'll Have To Look For Another Solution.

Very interesting!

: Linux Server: Hosting The Database

Ok, no problem here.

: Windows 2003 Server: Hosting The Program For Multiple Users

All right. do you mean that the program is running on Terminal Server? Or do you mean that there is one copy of the .exe, and it's on the Win2k3 server? Or do you mean something else?

: Local Win XP Pro Machine: Machine Used To Create And Compile .exe

OK there.

: Its Slow When Getting Information From The Database (Which Login Info Is Stored As Well). I've Figured Out That Its Not When Its Compiled That Its Slower, Its When It Gets Put On The 2003 Server, Which Means Its Not Anything To Do With The Program Itself, Its A Networking Issue (At Least I Think So).

Well, we need to know what you mean by "put on the server."

: When Ran Locally, It Could Connect Directly To The Database Server, But When Ran Off The Domain, It Would Have To Go Through Both Servers.

Well, not exactly. It doesn't "go through" both servers, but it gets data from one. I still don't know what Win2k3 is doing, though.

: Next Step Is For Me To Run It Directly From The Domain, And See If Its As Fast As Running It Locally.

This sounds like you are running Terminal Server...

: If This Isnt The Case, Then I'll Have To Look For Another Solution.

Well, that's for sure!

Post more info on what Win2k3 is doing. That may be the key to all of this...



Melissa

: Very interesting!
:
: : Linux Server: Hosting The Database
:
: Ok, no problem here.
:
: : Windows 2003 Server: Hosting The Program For Multiple Users
:
: All right. do you mean that the program is running on Terminal Server? Or do you mean that there is one copy of the .exe, and it's on the Win2k3 server? Or do you mean something else?
:
: : Local Win XP Pro Machine: Machine Used To Create And Compile .exe
:
: OK there.
:
: : Its Slow When Getting Information From The Database (Which Login Info Is Stored As Well). I've Figured Out That Its Not When Its Compiled That Its Slower, Its When It Gets Put On The 2003 Server, Which Means Its Not Anything To Do With The Program Itself, Its A Networking Issue (At Least I Think So).
:
: Well, we need to know what you mean by "put on the server."
:
: : When Ran Locally, It Could Connect Directly To The Database Server, But When Ran Off The Domain, It Would Have To Go Through Both Servers.
:
: Well, not exactly. It doesn't "go through" both servers, but it gets data from one. I still don't know what Win2k3 is doing, though.
:
: : Next Step Is For Me To Run It Directly From The Domain, And See If Its As Fast As Running It Locally.
:
: This sounds like you are running Terminal Server...
:
: : If This Isnt The Case, Then I'll Have To Look For Another Solution.
:
: Well, that's for sure!
:
: Post more info on what Win2k3 is doing. That may be the key to all of this...
:
:
:
: Melissa
:
:

Windows 2003 Is A Domain Server, Which All Users Connected To The Network Login To. Users Connect Directly To The Domain Server, And Execute The Program From There. It Is In A Folder On The Domain Server. Terminal Services Is Set Up, On A 4th Computer, But I'm Not Dealing With That At The Moment.

Can you try to copy the .exe from the Win2k3 server to a workstation? Then see if it's any faster...

I'm trying to think of a reason to have the program only on the server, and I can't. That's the way we did things in "the old days", but there's usually not much reason to do that today...

Does the app require any supporting files besides the .exe? Is the runtime installed on the individual workstation, or only on the server?

If only on the server, that's probably what's slowing things down. I'd make sure that the runtime, exe, and any supporting files (.ocx, etc) are on the workstation, and see how that goes.

If the concern is security and/or ease of updates, there are better ways of handling that than having the files live on the server...


Melissa

: Can you try to copy the .exe from the Win2k3 server to a workstation? Then see if it's any faster...
:
: I'm trying to think of a reason to have the program only on the server, and I can't. That's the way we did things in "the old days", but there's usually not much reason to do that today...
:
: Does the app require any supporting files besides the .exe? Is the runtime installed on the individual workstation, or only on the server?
:
: If only on the server, that's probably what's slowing things down. I'd make sure that the runtime, exe, and any supporting files (.ocx, etc) are on the workstation, and see how that goes.
:
: If the concern is security and/or ease of updates, there are better ways of handling that than having the files live on the server...
:
:
: Melissa
:
:

It Has Been Tested On A Local Machine, And Is Faster. This Program Is Used By Many People, And The Reason Its On The Domain Server Is Because It Is Easier To Update, To Keep The Logs All Together In One File, And So That It Can Be Managed Easier. There Are Multiple Files That Contain Things Like A Change Log, Help Files, Reports, And Stuff Like That. This Program Gets Updated Almost On A Daily Basis, So I Thought It Would Be Most Efficient To Run It Off The Server.

: It Has Been Tested On A Local Machine, And Is Faster. This Program Is Used By Many People, And The Reason Its On The Domain Server Is Because It Is Easier To Update...

I thought that might be a reason. Why not use some other means of updating? Replication? Login script? Code the update into the program?


:...To Keep The Logs All Together In One File, And So That It Can Be Managed Easier. There Are Multiple Files That Contain Things Like A Change Log, Help Files, Reports, And Stuff Like That...

Why aren't the log files and reports in the database? That would be the most efficient place, no?

: This Program Gets Updated Almost On A Daily Basis...

That's interesting. Do the user needs change that often? Or are there things hard-coded in the prograt that necessitate daily updates?

It sounds like you have more things that ought to be in the database. It's not efficient to have to update and re-compile the program daily.

I'm guessing that you have things in dropdown boxes that you're adding to daily?

There really has to be a better way to do this than you've already got.

I've done years of corporate programming, so I've been faced with similar issues in the past. But a better design is usually the best solution.

Example: Your company opens a new branch out of state. You need to run this app over a WAN. If you think it's slow now...

If all these logs and such were in the database, the program would function very well over a WAN...


Melissa

Updates Are For Added Functionality. This Program Is A Full Time Job. Always New Things Being Added. The Dropdown Items Come From A Lookup Table In The Database. The Reason For The Logs Being Stored Locally, Is Because There Is An Error Log, And If The Error Is Something Like Network Problems, Theres No Way To Log It, Because Network Access Is Required. This Company Will Not Expand. It Has One Main Office, And 7 Other Locations That Access This Program From Terminal Services. As For The Reports, That Part Isn't Complety Finished. There Actually Isnt Any Reports Stored On The Domain Server Now. Just Temporary Ones, That Get Erased After They're Closed.

: Updates Are For Added Functionality. This Program Is A Full Time Job. Always New Things Being Added. The Dropdown Items Come From A Lookup Table In The Database. The Reason For The Logs Being Stored Locally, Is Because There Is An Error Log, And If The Error Is Something Like Network Problems, Theres No Way To Log It, Because Network Access Is Required. This Company Will Not Expand. It Has One Main Office, And 7 Other Locations That Access This Program From Terminal Services. As For The Reports, That Part Isn't Complety Finished. There Actually Isnt Any Reports Stored On The Domain Server Now. Just Temporary Ones, That Get Erased After They're Closed.
:

The exe and supporting files should be installed on the local workstations. If you are putting/running the files from the server, for the ease of updating, then you could utilize some versioning functionality in the program to handle this for you. Have it automated. For example, in the startup exe test if the version# for the workstation matches the one on the server and copy the updates to the workstation. We use this strategy with several Access and VB apps - it reduced the maintenance to only update the server files while the workstation performs updates as the users log in.