Sep 11th, 2000, 06:27 PM
This one might just fascinate you =)
DAO
Access 97 Database
VB6 (orig. VB5)
Typical Client Company: NT server with multiple workstations running Windows 98
(I apologize for the length of this post, but I felt it necessary. I look forward to a discussion.)
Okay. Everything works wonderfully with my program, except for one thing: some of my clients are interested in sharing data between different locations. A location in this sense would ordinarily be a local network with one copy of the database on the server, with any number of clients connected to it. I am looking for a way to globalize (to coin a word) the database, so that each location could, if they chose, have a central location/server, instead of multiple, local servers, and in doing so, share data with no extra step involved. (where an extra step could be any number of ways to share information between the locations... something I am not familiar with either. If this extra step is easy, I am listening.)
Background info done =)
How would this normally be accomplished? The program itself has the ability to change the database that it is pointing to (to any valid path in Windows). So far, the only solution I've come up with is to map a drive through Network Neighborhood on the clients to \\<IP>\Shared. It does work, but the drive is slower than you'd expect, and does not use all the bandwidth available to it. (Even just copying a file to it does not go as quickly as it should!) So, the program is ordinarily quite fast, but it becomes unacceptably slow when the workstations are connected to a database that is accessed through this drive (i.e., through the internet to another computer with the database on it). Most of the time delays appear to occur when updating a recordset, or calling a query (and understandably so). Some of these can be measured in seconds! The initial connection to the database takes 10 seconds, but one-time delays are not a big issue. (Anything I can convert to one-time delays are a great plus, but I've only met with limited success, or an admitted case where it simply should have been less database-dependent)
I am looking for solutions, but I'm also interested in the concept in general. Mapping a drive to the host computer seemed obvious to me, but it's unusually slow. I'm looking for any solutions that work, either a miraculous way to speed up the "drive", or new approaches. The small company I work for is anxious to prove that we can beat our competitors at this game. (Who provide a hodgepodge mix of DOS, Windows, and dumb-terminal Unix-ish programs... some that have this ability but only painfully slowly, and I don't know that any of them use relational databases... we're talking acient technology. It is generally acknowledged that we have the best program in the market for what we do, but only if our program fits the specific customer, we don't "cover quite all the bases" for many larger customers, and we're clawing at the mid-range customers... but this would make a dent!)
All comments appreciated.
Mark Delano
PS - I seem to get about 8K per second through my DSL on my q: drive that is really a folder on my computer at home (which is on cable). This is VERY cool... I used to use an ftp program to upload to a site from work, and download from home. Normally, I can get a minimum 25K/s on DSL, and the cable is faster. It may only be that this is the wrong way to go about it, and that the computers aren't designed for this. Any thoughts?
PPS - If I can get it to work full speed over cable, at 70K+ bytes/sec (read: an 8 to 10 time speed increase), it would really solve the problem, and 25K/s might be acceptable with some internal optimizations in the program. I'll say one thing, it has helped me find unnecessary database calls! They sure stick out =) Thanks! I hope we can solve this one! =)
DAO
Access 97 Database
VB6 (orig. VB5)
Typical Client Company: NT server with multiple workstations running Windows 98
(I apologize for the length of this post, but I felt it necessary. I look forward to a discussion.)
Okay. Everything works wonderfully with my program, except for one thing: some of my clients are interested in sharing data between different locations. A location in this sense would ordinarily be a local network with one copy of the database on the server, with any number of clients connected to it. I am looking for a way to globalize (to coin a word) the database, so that each location could, if they chose, have a central location/server, instead of multiple, local servers, and in doing so, share data with no extra step involved. (where an extra step could be any number of ways to share information between the locations... something I am not familiar with either. If this extra step is easy, I am listening.)
Background info done =)
How would this normally be accomplished? The program itself has the ability to change the database that it is pointing to (to any valid path in Windows). So far, the only solution I've come up with is to map a drive through Network Neighborhood on the clients to \\<IP>\Shared. It does work, but the drive is slower than you'd expect, and does not use all the bandwidth available to it. (Even just copying a file to it does not go as quickly as it should!) So, the program is ordinarily quite fast, but it becomes unacceptably slow when the workstations are connected to a database that is accessed through this drive (i.e., through the internet to another computer with the database on it). Most of the time delays appear to occur when updating a recordset, or calling a query (and understandably so). Some of these can be measured in seconds! The initial connection to the database takes 10 seconds, but one-time delays are not a big issue. (Anything I can convert to one-time delays are a great plus, but I've only met with limited success, or an admitted case where it simply should have been less database-dependent)
I am looking for solutions, but I'm also interested in the concept in general. Mapping a drive to the host computer seemed obvious to me, but it's unusually slow. I'm looking for any solutions that work, either a miraculous way to speed up the "drive", or new approaches. The small company I work for is anxious to prove that we can beat our competitors at this game. (Who provide a hodgepodge mix of DOS, Windows, and dumb-terminal Unix-ish programs... some that have this ability but only painfully slowly, and I don't know that any of them use relational databases... we're talking acient technology. It is generally acknowledged that we have the best program in the market for what we do, but only if our program fits the specific customer, we don't "cover quite all the bases" for many larger customers, and we're clawing at the mid-range customers... but this would make a dent!)
All comments appreciated.
Mark Delano
PS - I seem to get about 8K per second through my DSL on my q: drive that is really a folder on my computer at home (which is on cable). This is VERY cool... I used to use an ftp program to upload to a site from work, and download from home. Normally, I can get a minimum 25K/s on DSL, and the cable is faster. It may only be that this is the wrong way to go about it, and that the computers aren't designed for this. Any thoughts?
PPS - If I can get it to work full speed over cable, at 70K+ bytes/sec (read: an 8 to 10 time speed increase), it would really solve the problem, and 25K/s might be acceptable with some internal optimizations in the program. I'll say one thing, it has helped me find unnecessary database calls! They sure stick out =) Thanks! I hope we can solve this one! =)