Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
Keeping External Modules in Sync With Database Version |
Tue, Oct 6 2009 10:18 AM | Permanent Link |
"Terry Swiers" | Hi,
I'm just curious as to how others here are dealing with keeping external modules in sync with database changes in a client server environment. I was hoping to keep the server installation clean with only the server engine itself and have the application manage the database schema and external modules. That way, the end user only needs to keep the application up to date and doesn't have to worry about keeping the server and the application in sync. Any feedback on how others are doing this would be greatly appreciated. -- --------------------------------------- Terry Swiers Millennium Software, Inc. http://www.1000years.com http://www.atrex.com Atrex Inventory Control/POS - Big business features without spending big business bucks! Atrex Electronic Support Options: Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp Email: mailto:support@atrex.com Newsgroup: news://news.1000years.com/millennium.atrex Fax: 1-925-829-1851 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific) --------------------------------------- |
Tue, Oct 6 2009 12:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Terry,
<< I'm just curious as to how others here are dealing with keeping external modules in sync with database changes in a client server environment. I was hoping to keep the server installation clean with only the server engine itself and have the application manage the database schema and external modules. That way, the end user only needs to keep the application up to date and doesn't have to worry about keeping the server and the application in sync. >> I would use the server as the main conduit for distributing updates to the application. That way it can manage the transition to a new package of external modules and database schema changes without requiring the application to do anything other than to download the latest version of the application (you can use stores for this functionality, just have the application check a designated store on the server for a new version of the application every time it connects). -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Oct 6 2009 2:34 PM | Permanent Link |
"Terry Swiers" | Tim,
> I would use the server as the main conduit for distributing updates to the > application. That way it can manage the transition to a new package of > external modules and database schema changes without requiring the > application to do anything other than to download the latest version of > the application (you can use stores for this functionality, just have the > application check a designated store on the server for a new version of > the application every time it connects). I'll have to think about this. Since we are supporting multi-user in C/S and direct access to the data, I'll have to see if there is a way that I can get something like this to work for both scenarios. Thanks again. -- --------------------------------------- Terry Swiers Millennium Software, Inc. http://www.1000years.com http://www.atrex.com Atrex Inventory Control/POS - Big business features without spending big business bucks! Atrex Electronic Support Options: Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp Email: mailto:support@atrex.com Newsgroup: news://news.1000years.com/millennium.atrex Fax: 1-925-829-1851 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific) --------------------------------------- |
Wed, Oct 7 2009 3:43 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Terry
If you do be sure to post about it. Roy Lambert |
Wed, Oct 7 2009 1:22 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Terry,
<< I'll have to think about this. Since we are supporting multi-user in C/S and direct access to the data, I'll have to see if there is a way that I can get something like this to work for both scenarios. >> You can still do it, you'll just use a store that is defined in the common configuration file that all users access. If you think about it, nothing changes between multi-user and C/S except the transport protocol and who updates/reads the data. All of the stored procedures, stores, etc. all stay the same. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Oct 9 2009 12:46 PM | Permanent Link |
"Terry Swiers" | Tim,
> You can still do it, you'll just use a store that is defined in the common > configuration file that all users access. If you think about it, nothing > changes between multi-user and C/S except the transport protocol and who > updates/reads the data. All of the stored procedures, stores, etc. all > stay the same. Ah, but if I were starting from scratch on the application, this would be my approach. Unfortunately, I'm working with an application that I ported over from DBISAM. It's hardcoded throughout the application to use two specific database names (it can access two databases at the same time to transfer information back and forth) so it would be pretty much impossible to convert it over to using different database names in the timeframe that I'm working under. So at this point, I'm using a separate configuration file for each directory/database. I know it makes things difficult, but it's kind of what I'm stuck with at this point. Speaking of which, there was mention of keeping the configuration files in a different folder other than the actual database itself. Is there a reason for this? -- --------------------------------------- Terry Swiers Millennium Software, Inc. http://www.1000years.com http://www.atrex.com Atrex Inventory Control/POS - Big business features without spending big business bucks! Atrex Electronic Support Options: Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp Email: mailto:support@atrex.com Newsgroup: news://news.1000years.com/millennium.atrex Fax: 1-925-829-1851 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific) --------------------------------------- |
Fri, Oct 9 2009 3:56 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Terry,
<< Unfortunately, I'm working with an application that I ported over from DBISAM. It's hardcoded throughout the application to use two specific database names (it can access two databases at the same time to transfer information back and forth) so it would be pretty much impossible to convert it over to using different database names in the timeframe that I'm working under. So at this point, I'm using a separate configuration file for each directory/database. >> There really isn't anything in that design that dictates that you use a separate configuration file for each database, at least none that I can see from that description. And there would be no change in the application since the database names do not change. In fact, I would say that you had to go out of your way to use two different configuration files instead of just one. << Speaking of which, there was mention of keeping the configuration files in a different folder other than the actual database itself. Is there a reason for this? >> It's to allow for easier dealings with the database files (catalog and table files). If you include the configuration file in the database directory, then you can't just delete or copy the contents of the database directory without taking out the configuration file also in the process. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Oct 9 2009 5:20 PM | Permanent Link |
"Terry Swiers" | Tim,
> There really isn't anything in that design that dictates that you use a > separate configuration file for each database, at least none that I can > see from that description. And there would be no change in the > application since the database names do not change. In fact, I would say > that you had to go out of your way to use two different configuration > files instead of just one. Ok. Here is more detail. Any given end user of ours may have multiple databases in a multi-user environment, each of which are in separate folders. For simplicity sake, I'll call them A, B, and C. When our application opens up and connects to any database, it's given the name "Primary". If the application needs to transfer or access information from a secondary location, it connects to the other database using the name of "Secondary". So our application sitting on workstation 1 may be connected to "A" as database name "Primary" and "B" as Secondary", while workstation 2 may be connected to "B" as "Primary" and "C" as secondary. And to make things even more interesting, a user may be running multiple instances of our application, each of which points to a different database. If I use a single configuration file for all of these, I either have to rework the application to allow for dynamic names for the databases or I end up with a problem when one instance wants the database "Primary" to point to database A and another that wants it to point to database B. > << Speaking of which, there was mention of keeping the configuration files > in a different folder other than the actual database itself. Is there a > reason for this? >> > > It's to allow for easier dealings with the database files (catalog and > table files). If you include the configuration file in the database > directory, then you can't just delete or copy the contents of the database > directory without taking out the configuration file also in the process. Got it. Thanks. -- --------------------------------------- Terry Swiers Millennium Software, Inc. http://www.1000years.com http://www.atrex.com Atrex Inventory Control/POS - Big business features without spending big business bucks! Atrex Electronic Support Options: Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp Email: mailto:support@atrex.com Newsgroup: news://news.1000years.com/millennium.atrex Fax: 1-925-829-1851 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific) --------------------------------------- |
Sat, Oct 10 2009 4:29 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Terry,
<< So our application sitting on workstation 1 may be connected to "A" as database name "Primary" and "B" as Secondary", while workstation 2 may be connected to "B" as "Primary" and "C" as secondary. And to make things even more interesting, a user may be running multiple instances of our application, each of which points to a different database. If I use a single configuration file for all of these, I either have to rework the application to allow for dynamic names for the databases or I end up with a problem when one instance wants the database "Primary" to point to database A and another that wants it to point to database B. >> Ahh, so "Primary" and "Secondary" are hard-coded names in the application ? If so, then yes, you would need to change that so that the database name can change in order to make it work. However, unless you're using database names everywhere in the SQL code, this type of change should be a simple matter of changing the TEDBDatabase.Database property. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, May 3, 2024 at 06:06 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |