>How about having a data directory filled with the data
>structure needed for newly defined 'companies' and
>keep them free of records. This would represent the
>'replication pool'.
>
>Anytime a new company is defined, a new data directory
>gets created and the replication pool gets copied in.
>
>- Chris
>
>>>

>>>* cNewDBC and cNewFreePath are public vars
>>>* Changes database and free table paths at runtime
>>>nMembers = amembers(aCursors,this,1)
>>>for ix = 1 to nMembers
>>>	if aCursors[ix,2] = "Object" and this.&aCursors[ix,1]..baseclass = "Cursor"
>>>		if !empty(this.&aCursors[ix,1]..database)  && Cursor is not free
>>>			this.&aCursors[ix,1]..database = cNewDBC
>>>		else			&& Cursor is a free table
>>>		    oldCursor = this.&aCursors[ix,1]..cursorsource
>>>		    newCursor = cNewFreePath + ;
>>>		        iif(right(cNewFreePath,1) = "\","",;
>>>		        iif(empty(cNewFreePath),"","\"))+;
>>>		    	substr(oldcursor,rat("\",oldCursor)+1)
>>>		    this.&aCursors[ix,1]..cursorsource = newCursor	
>>>		endif	
>>>	endif
>>>endfor
>>>

>>>But of course in the case of Chris, I would suggest still using only one dbc and tables of it, with one extra field "Company" added and filter set as needed.
>>>Cetin
>>
>>Now this is where DBC is an obstacle. Having separate subdirectories is very handy sometimes, since it reduces network traffic (imagine a situation where each group of users has a directory for themselves). With free tables it's an easy thing to do - with DBCs you either have to replicate the DBC for each new directory, or replicate the tables' info in the DBC for each new subdirectory, but then you need exclusive access to the DBC.
>>
>>This may be an item for the WishList_ga - there should be a way for two tables of identical structures to share the same definition within a DBC, no matter the directory where they reside, or have DBC hierarchy, like class model - this table inherits the structure and behavior of some other table... Usually when I hear myself dreaming like this, I end up writing the stuff myself, but in case of DBCs I have serious doubts on possible effects of such an enterprise - as much as I've mucked around the DBCs, there are too many things to them that are not hardcoded - they are hammered and welded into VFP.
>>
>>Really, is there an easy workaround for this situation?
Hi Chris,
At first it sounds good to have a separate dir for each company. But this would slow down the system as the number of companies grow. For example one day might there be 1000 companies leading 1000 subdirs and searching for subdirs is really slow compared to table search and/or filter. Instead, one master table holding companies and some static info about them, IMO is a better approach than having them in separate dirs. As filecount on system grow performance degrades. MSOffice findfast, virus scan apps etc would expose other problems. There would be a lot of wasted space (only the smallest table header would waste at least 4K).
Also there would be a set of tables and dbc replicated (empty) for each of the companies. Just one test about it, create 1000 dirs as dir0001, dir0002 etc and copy a simple text file to each of them, then try to just open and close in each dir in code via a for loop and see the elapsed time. If a fast machine than do it with 10000 dirs. Also if by mistake these dirs are to be opened at root would fail miserably at a max of 512 dirs.
Another point would be backups. bak file count is likely to be at least companycount times more.
Of course as Dragan said it could be sometimes handy having seperate dirs to reduce the traffic. But here too I think using param. views could be more effective too.
Cetin