![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 2 of 2 total |
![]() |
Tue, Aug 14 2012 1:07 AM | Permanent Link |
John Taylor | I'm hoping someone can help me alleviate some fears that I have in
converting our existing fax server/client software applications to use dbisam (4.33) to client server. Here's the scenario: We have a fax server application that runs on one computer on a network , this application transmits and receives faxes and logs the incoming and outgoing faxes to a local database, *usually* on the same machine as the application but users have the option to select any location they want for the database, sometimes they choose a network drive on another machine. The client software application interacts with the server's local database in several ways, when an outgoing fax job is 'submitted' to the fax server, the client app writes a record to a jobs table in the server's database. The fax server app scans this periodically looking for jobs to process. The client app also 'imports' received faxes to its local database from the server's database and also updates the status of jobs it has submitted to the server (and written to its local database) by examining the state of the server's jobs table and faxes sent table. All of this works ok but we have some users with large databases on the server and maybe as many as 30 client machines hammering on the server tables. The databases have several blob fields to store fax images, log files, etc. and the problems we do encounter now are typically with the blob files, and corruption BLOB offset problems etc. where repair of the database becomes necessary. I am hoping that moving to client server will alleviate that problem. Aside from the fact that many of our users are naïve and I'm expecting tech support headaches with regard to dbserver administration, I have the following other concerns: 1. Properly installing the dbserver as a service and pointing it to the location where the fax server's data is currently located. The location is maintained in a registry entry on the fax server but the data path may be anywhere. 2. The installer for the fax server application would be used to install the dbserver, so getting the fax server app retooled for client server is not a major concern, but as is often and usually the case, customers will update the client software and not update the fax server software to the latest versions. This will result in a client app trying to suddenly use remote sessions when the dbserver has not been installed. If customers would install the latest update for both, this would not be such a sticking point but they will not do that typically. The reverse may also happen where a customer updates the fax server app but not the client app, so then we have the dbserver installed with the server using remote sessions to access the same tables that the prior version of the client app is accessing with local sessions. I'm sure that won't be pretty ![]() 3. As I understand it, all of my tables, queries, etc. will work fine as is and the only change would be to change the session type to remote from local, is it really that simple ? 4. My biggest fear of course, is a swamp of tech support queries and problems raining down after the updates to client server are published. Sorry for the long post but I really need to get over my fear about this and take the plunge. ![]() Thanks JT |
Tue, Aug 14 2012 5:53 AM | Permanent Link |
Fernando Dias ![]() | John
<< Aside from the fact that many of our users are naïve and I'm expecting tech support headaches with regard to dbserver administration>> DBISAM dbserver administration requirements are near to nothing Also, the administration utility is very straight forward. If the server is properly installed as a service, I'd say you can almost forget it exists ![]() << The location is maintained in a registry entry on the fax server but the data path may be anywhere.>> I'd change the rules here. The database should *always* be in the same machine as the dbserver or you would be completely defeating the benefits of C/S. The fax server would have a setting indicating where the dbserver is ( the IP or hostname, as you wish ) and that could be the fax server machine or any other, but the database would always be in the same machine where the DBISAM server is. Also, if the fax server uses C/S then all the clients should also use C/S for accessing the "central" database, and local sessions only for the local databases. The "central" database tables would only be "touched" by DBISAM server, that is in the same machine. << server using remote sessions to access the same tables that the prior version of the client app is accessing with local sessions >> That is already happening, with your current setup, the clients might be accessing the same tables using different engine versions, as well as the fax server. In general, It's not an issue if only the release numbers are different i.e. 4.33.1 to 4.33.2 , but it can be an issue for minor release updates. You wont have different versions opening the tables, because only the DBServer is going to access them, but you are going to have different client versions talking to the db server, and that can be an issue, but its easy to avoid. Just make your client applications check the versions at startup and do now allow them to run if the client and dbserver are not running the same version. <<3. As I understand it, all of my tables, queries, etc. will work fine as is and the only change would be to change the session type to remote from local, is it really that simple ? >> There are a couple of things that you might have change, but they might not apply to your case, for example, if you need to copy entire tables from server to clients or the backup path (its going to be relative to the server, not the clients) and atm I can't think of any other ... Also, there might be some optimization aspects to consider, but everything is going to work. << My biggest fear of course, is a swamp of tech support queries and problems raining down after the updates to client server are published.>> I believe it's going to be the opposite, after an initial period of adaptation, of course. Don’t make it in a rush, give yourself some time to get familiar with the concept before involving your customers, and if you can, choose one to be your tester before releasing it to the others . Good luck ![]() -- Fernando Dias [Team Elevate] |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |