Pergunta é básica, tenho no meu banco relacionamentos N para N ( muitos pra muitos, * - *, enfim).
Pergunta é… como faço o scriptcase tratar essa rotina de inserção, alteração, exclusão nesse relacionamento?
Fiz algo próximo, mas tb tive problema, cenário:
tbendereco, tbcliente, tbtransportadora, tanto cliente quanto transportadora tem n-m com endereço, fiz cadastrar usando o evento after insert… até ai tudo bem, funcionou ok, criei variavel de sessao e a usei para o cadastro no form detalhe, porem, para visualizar por ex os clientes, está mostrando todos os endereços, não há uma ligação direta entre endereco e cliente, pois tem a tabela n-m no meio, ai deu problema 
já tentei de tudo quanto é maneira, são 5h51 da manhã, só hoje to mexendo com isso desde as 22h e não encontrei solução
e não me venham falar que terei que fazer uma endereço para cada uma e fazer ligação 1-n senão eu piro uheaueahueahuae
abço… já agradeço se alguem puder ajudar.
Obrigado.
Já resolveu o problema?
Se não, como está a tabela de endereço?
Quando preciso algo parecido eu crio mais tabelas pra fazer as ligações… não é o ideal, mas pelo menos funciona…
neste caso por exemplo:
[tt]tabela clientes_enderecos
- cli_id
- endereco_id[/tt]
[tt]tabela transportadoras_enderecos
- transp_id
- endereco_id[/tt]
Daí nos selects é só usar joins e nos cadastros utilizar o recurso “atualizar tabela de ligação”… dependendo do caso dá pra juntar tudo numa única tabela de ligação tbm (cli_id, endereco_id e transp_id)…
Espero ter ajudado.
Att.
Robson
Questão interessante esta heim… , vamos lá estudar um pouquinha de estrutura de dados… rs rs
Quando existe um relacionamento N:N, você acaba tendo que ter ‘no meio’ uma tabela de ligação ou junção de forma a não ferir a integridade referencial entre as tabelas envolvidas, desta forma a sugestão do Robson é válida.
William .’.
Se entendi o cenário eu faria mais ou menos assim:
Neste primeiro cenário você tem uma tabela guadando APENAS 1 endereço para um cliente como para um fornecedor.
TB_ENDERECO
ID*
ENDERECO
.
.
.
TB_CLIENTE
ID
IDENDERECO*
CLIENTE
.
.
.
TB_TRANPORTADORA
ID
IDENDERECO*
TRANSPORTADORA
.
.
.
Neste outro cenário você tem uma tabela guadando tanto quanto forem necessários, endereço para um cliente como para uma tranportadora
TB_ENDERECO
ID
ENDERECO
IDCLIENTE¹
IDTRANPORTADORA²
.
.
.
TB_CLIENTE
ID¹
IDENDERECO
CLIENTE
.
.
.
TB_TRANPORTADORA
ID²
IDENDERECO
TRANSPORTADORA
.
.
.
Levando este cenário para o SC, numa mestre/detalhe, o detalhe é limitado pelo IDCLIENTE ou IDTRANSPORTADORA. Assim, ele lista todos os endereços de um cliente e todos os endereços de uma transportadora.
Os DBAs que me descupem, mas desta forma nem precisa fazer relacionamentos do banco. As vezes temos de abrir mão de algumas regras de modelagem em detrimento de alguma recompensa na camada da aplicação. Alguns bancos são tão normalizados que na hora que fazer a aplicação dá um trabalho que só. Se você tiver o cuidade de validar bem a entrada de dados na aplicação os relacionamentos em alguns casos são dispensáveis.
então no meu caso:
TBClientes
CNPJ
Endereco
ID_CPF_FUN
.
.
.
TBFuncionarios
CPF
Endereco
.
.
.
No Mestre/detalhe eu limito pelo ID_CPF_FUN? e evito de usar uma terceira tabela do tipo: TBClientes_TBFuncionarios?
costumo colocar um campo “origem” pra saber de onde é. tipo … clientes a origem é 1, fornecedor a origem eh 2 …