Subject | Query / join question |
---|---|
Author | Nico Callewaert |
Post date | 2001-05-18T18:57:03Z |
Hi,
I have a little problem. I have a query like this :
SELECT A.OrderNo,
A.CustNo,
A.... etc, etc,
B.Name
FROM Order_Comm A
JOIN Cust B ON B.CustNo = A.CustNo
WHERE A.OrderNo = :qOrderNo
Keyrelation set to Order_Comm
Everything ok, but the users of my application were complaining, when they insert a new order, after they entered the customer number, they expect to see immediatly the name of the customer. Of course the name only appears after they save the record. After that I decided to remove the JOIN and use a seperate query to retrieve the customers name, by setting KeyLinks and KeySource. They get what they asked, but the problem is the customers table is getting bigger and bigger, now I already have approximatly 3000 records. With KeyLinks doesn't seem the best solution. A table with 3000 records cannot be called "lookup table" anymore. How could I solve this the best ?? All I know some users could be tough.
Many thanks in advance,
Nico Callewaert
[Non-text portions of this message have been removed]
I have a little problem. I have a query like this :
SELECT A.OrderNo,
A.CustNo,
A.... etc, etc,
B.Name
FROM Order_Comm A
JOIN Cust B ON B.CustNo = A.CustNo
WHERE A.OrderNo = :qOrderNo
Keyrelation set to Order_Comm
Everything ok, but the users of my application were complaining, when they insert a new order, after they entered the customer number, they expect to see immediatly the name of the customer. Of course the name only appears after they save the record. After that I decided to remove the JOIN and use a seperate query to retrieve the customers name, by setting KeyLinks and KeySource. They get what they asked, but the problem is the customers table is getting bigger and bigger, now I already have approximatly 3000 records. With KeyLinks doesn't seem the best solution. A table with 3000 records cannot be called "lookup table" anymore. How could I solve this the best ?? All I know some users could be tough.
Many thanks in advance,
Nico Callewaert
[Non-text portions of this message have been removed]