Re: Help with an SQL join.
Quote:
Originally Posted by sotoasty
That's what database are designed for. So you can quickly and easily query data to get the results you want.
Yes, that is what databases are designed for but frequent hits to the database can slow up the application. Especially, when the database server is not the same as the one on which the application is running. Now, since this much has been talked of upon the performance issues, I would even suggest using stored procedures in this case instead of using dynamically built queries so that they would help in the faster processsing of the data on the DB server (compilation of query skipped, execution plan once generated re-used etc.)
Quote:
Originally Posted by sotoasty
You should be checking for failures anyway.
Yes :) . I fully agree to it (and also mentioned this in my last post).
Quote:
Originally Posted by sotoasty
And if you have everything in memory, you can't do alot with the data if the network/database fails anyway.
They are sometimes very helpful and fast up the processing on the client side. This is one of the benefits that we extract out of the ADO.NET Dataset objects and the concept of offline databases(Apologies for bring ADO.Net reference in the VB 6.0 forum but the logic holds true.)They are very helpful as far as web-applications go and the concept can be used here as well in a typical client server model. I mean, what is the problem if I load the related data for a form until the time the form lives?
Quote:
Originally Posted by sotoasty
Also, as I pointed out earlier, when you start to add clients and accounts, the data you are going to start pulling across the network will far outway the traffic of the queries. Not to mention, you will now have the latest data. And you won't have to worry about those pesky refreshes. More network traffic.
For such serious troubles, yes possibly it won't help but for minor short lived disturbances they can be helpful. Also, when the network traffic on the database increased due to increase in the expected number of client users interacting with the DB. That may be short lived..right? And hence can even lead to deadlocks (I know I being very pessimistic here but yes..there can be occurences of these).
sotoasty, I agree to you on most of the points. But, IMO creating collections of Accounts and Client data seems to be very appropriate (I did not expand much on it but this was the best way IMO and I even mentioned in the end) and we even used this kind of methodology a lot in my last VB 6.0 project that I did about 2 years ago. They are always appreciated in terms of performance. But, yes as JonnyPoet says that these two are the possible solutions and it depends on the OP's understanding which one suits his/her application the best :) . Best Regards.
