Mas havia outro tipo de multitabela, e separar facilitou muito.
Querendo ou não, é vício de DBF: economizar arquivos
Então eu tinha lá num determinado arquivo, um campo com uma lista de códigos.
Isso precisa rotina específica
Encontra( AUX_LICOBJ + StrZero( nIdLicObj, 6 ), "jptabel", "numlan" )
FOR nCont = 1 TO Len( Trim( jptabel->axParam03 ) ) STEP 6
cTemp := Val( Substr( jptabel->axParam03, nCont, 6 ) )
IF cTemp != 0
AAdd( mlcLicList, { cTemp, Ctod(""), 0, 0 } )
ENDIF
NEXT
FOR nCont = 1 TO Len( mlcLicNum ) STEP 8 // igual data
cTemp := Val( Substr( mlcLicNum, nCont, 6 ) )
IF ! Empty( cTemp )
nNumLic := hb_ASCan( mlcLicList, { | e | e[ LIC_CODIGO ] == cTemp } )
IF nNumLic != 0
Encontra( AUX_LICTIP + StrZero( mlcLicList[ nNumLic, LIC_CODIGO ], 6 ), "jptabel", "numlan" )
mlcLicList[ nNumLic, LIC_DATA ] := hb_Stod( Substr( mlcLicDat, nCont , 8 ) )
mlcLicList[ nNumLic, LIC_VALIDADE ] := Val( jptabel->axParam01 )
mlcLicList[ nNumLic, LIC_PRAZO ] := Val( jptabel->axParam02 )
ENDIF
ENDIF
NEXT
Então tinha rotina parecida pra mostrar, pra GET, pra salvar, etc.
Sempre todos os códigos de uma vez, afinal, é um campo "linguição" com vários códigos.
Ao dividir essa tabela em duas, troquei a rotina por um simples BROWSE.
E a rotina de edição passou a ser apenas a edição do código atual.
Muito mais simples do que antes.
Até poderia ficar parecido em DBF... mas em DBF a gente tá acostumado a pensar em economizar arquivo, por causa dos tempos do Clipper.
Para SQL, tanto faz, vai ser sempre uma única conexão, um comando e um retorno, tanto faz como isso é dividido pelas tabelas.
Aliás... pra SQL é bem melhor sem esse "linguição", assim a consulta é feita de tudo de uma vez.