>>>Create a local view in the dbc and requery that view when you need a new ID. Believe it or not, the following works for me:
>>>
>>>create sql view v_NextID as select lNextID(?cAlias) NextID from Kounters where Table_Name = ?cAlias
>>
>>Mark,
>>
>>This seems like a good approach and would ensure, that the correct SP is used. But it doesn't answer the second problem: should I use default value for Regions table or not.
>
>If the Regions table is the ONLY table that causes this problem, then I would not use a default value. Just use the view I suggested for this table only. Otherwise, you would be back in same situation as you were before. I see no way where you can put a function call to a SP that has the same name as a SP in another DBC for your specific situation. As I see it, you either have to change the names of the SPs to be different or use the view I suggested.

Mark,

I already renamed my SP, so now it's not a problem. However, here is a problem, which I described in another thread as well:

In a form I use three views: CustomerInfo (based on CustomerSpecific table), RegionsInfo (based on Regions table) and TownsInfo (based on TownRegions table).

CustomerInfo displayes only one record with the CustomerID=oJC.CustID In RegionsInfo we can add, edit, delete records. For TownsInfo I use some tricky mechanism: I have a multiselect grid based on Lookups!towns table. User can select records. When he/she saves the record, I insert selected towns + RegionID into TownsInfo. TownRegions table also has default value, which may cause problems as well. So, I believe, I have to clean up default values in both tables...