Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
User specific temp folders under c/s |
Mon, May 19 2008 4:51 PM | Permanent Link |
Chris Scarpinatto | Hello,
Sorry if this question is clueless... I am moving my app over to c/s and have one last thing I haven't been able to get right. I need each user to have his/her own separate temporary folder. Can the temp directory be set to something like "C:\Users\%username%" in the server admin tool? Any pointers to how to do this would be appreciated. TIA, Chris |
Mon, May 19 2008 4:57 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Chris,
<< I am moving my app over to c/s and have one last thing I haven't been able to get right. I need each user to have his/her own separate temporary folder. Can the temp directory be set to something like "C:\Users\%username%" in the server admin tool? Any pointers to how to do this would be appreciated. >> Sorry to answer a question with a question, but why do you need each user to have their own temporary files folder ? -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 22 2008 10:32 AM | Permanent Link |
K. C. Scarpinatto | Tim,
This is fallout from the way that we originally designed our reports. Rather than run the reports (we use ReportBuilder) off of the live tables, we run queries, save them out to disk as temporary tables, and then run the reports off of the temporary tables. Since several users could be running the same report at the same time, we handled this with user-specific temporary folders. The is the strategy we had used successfully for years in our legacy application done in Corel Paradox. Under local DBISAM in Delphi, it has worked just as well. I know that there are other options, like plugging the RBuilder data pipelines directly into TDBISAMQuery objects (so that there is no table written to disk), or changing the names of the result tables on the fly so that they include some string that makes each one unique. Before going and changing the code on all of the reports, I wanted to see if there was a way for us to continue with our strategy under client/server. If it isn't possible, we will just have to change. Chris "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: Chris, << I am moving my app over to c/s and have one last thing I haven't been able to get right. I need each user to have his/her own separate temporary folder. Can the temp directory be set to something like "C:\Users\%username%" in the server admin tool? Any pointers to how to do this would be appreciated. >> Sorry to answer a question with a question, but why do you need each user to have their own temporary files folder ? -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 22 2008 11:28 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Chris,
<< Before going and changing the code on all of the reports, I wanted to see if there was a way for us to continue with our strategy under client/server. If it isn't possible, we will just have to change. >> Well, the first issue is how to create a remote database for every single user, because that's what would be required in order to allow ReportBuilder to use the remote tables in a client application. You'll have to use these remote procedures in the client app (administrator log-in required) to create the remote databases "on-the-fly": http://www.elevatesoft.com/manual?action=mancompmethod&id=dbisam4&product=d&version=7&comp=TDBISAMSession&method=AddRemoteDatabase http://www.elevatesoft.com/manual?action=mancompmethod&id=dbisam4&product=d&version=7&comp=TDBISAMSession&method=AddRemoteDatabaseUser After that, you can direct any INTO clause or tables into the database by just referencing the name. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 22 2008 11:52 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
What would the effect be of simply using the memory database? Doesn't that isolate users? Could they each have a table of the same name? Roy Lambert |
Thu, May 22 2008 2:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< What would the effect be of simply using the memory database? Doesn't that isolate users? Could they each have a table of the same name? >> Yes, and yes. That's another good option, provided that the tables aren't particularly large. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 22 2008 3:14 PM | Permanent Link |
Chris Scarpinatto | Tim and Roy,
Thanks, that's two possible options. One further question---if I take the approach of dynamically creating individual remote databases, what is the cost? If a lot of dynamic databases were created, would we get a meltdown? The server we are using is Win2003 with 16 GB of RAM. I am estimating that we won't have more than 20-30 people on at any given time. Thanks! Chris "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote: Roy, << What would the effect be of simply using the memory database? Doesn't that isolate users? Could they each have a table of the same name? >> Yes, and yes. That's another good option, provided that the tables aren't particularly large. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 22 2008 4:28 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Chris,
<< Thanks, that's two possible options. One further question---if I take the approach of dynamically creating individual remote databases, what is the cost? If a lot of dynamic databases were created, would we get a meltdown? >> Nah. Although, I would suggest that you simply create them and leave them, especially if they're going to be used repeatedly. You can always clean up the unused databases later. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |