>>I have had speed issues in the multiuser environment and someone suggested >>that I place the dbc locally on the user's hard drive.<<
Are you referring to a DBC on the local machine and contained tables on the server? Or are you referring to a views-only DBC pointing to tables-only DBC on the server? If you are referring to a local DBC with tables on the server I would recommend not to do this. The DBC/DBF relationship is important and is stored in the tables. If one machine has a different mapping to the server the DBC/DBF relationship is likely broken. Even if the mapping is consistent, I would be leery of taking this approach. If it is a views-only DBC, it is okay. Opening a view will look for the database (provided you have databasename!tablename as part of the FROM and JOINs in the view definition) and if the DBC is in the path or already open, the app will find the tables. >>1. How do I place the DBC locally and still have the data on the server?<< The views-only DBC needs the tables-only DBC to be open or available on the path. Releasing the DBC to the end users will release all the views since they are stored in the DBC. >>2. How does this affect Stonefield updates?<< DBCX (underlying technology used by SDT) first needs to find the DBCX registration table DBCXReg.DBF. The update process will attempt to instantiate all the DBCX managers found and registered in the DBCXReg table. The update program also has to be able to find all the data registered in the DBCX and SDT extensions. If it can you will be okay. So the update program needs access and pathing to the DBCX files and all the application data. >>3. and How do I develop locally, and then deploy the finished product on a >>server? i.e. dbc local, data on server.<< It sounds like you are referring to a tables DBC here. Because of the pathing issue, you would have to make your development environment be exactly like the customer environment to get the relative pathing for the tables. Maybe this will make it more obvious why I think this is a bad idea. >> If I understand Stonefield update process, I place the dbc and related >> Stonefield files and Stonefield takes care of the update.<< Correct, this is all you have to do. >>Presently, I have a file on the server that is updated by the first user in >>the am. That is the signal to run Stonefield once. I lock users out of the system while the reindexing happens.<< One thing you might consider is creating a program that calls the update process and can be scheduled to run at night (Windows Scheduler works). This way the first user is not greeted with the process of reindexing. Maybe the data is small enough where this does not matter today, but someday the data might be large enough where this is a nuisance, and it will allow all the other users to get to work first thing in the morning. Rick White Light Computing, Inc. www.whitelightcomputing.com www.swfox.net www.rickschummer.com _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
