>Wow I wish we were getting that kind of performance. I find that there are two areas where I find issues. The first is very straight forward in my mind. BTW data size is about 3gigs total. Also you should know that the index file has lots of tags due integration of two other programs (skyline and an other). When I use a view (which is basicly a select statement using a get ?custno) to get a customer record it can take about a full minute or more. What I've noticed is the bottleneck is in the network (100baseTX full duplex, switched). It appears that a view requires that the entire index file be transfered to the workstation before it returns the record. I know this because at the workstation a tmp file is created and if I crash the computer during the transfer and inspect the file with debug after it turns out to be the index file. We have only about 50,000 customers but the index (cdx)is very large. Remember the other two programs add many tag's to the index file. However,
>if I use seek my_custno it comes back almost immediately. I can not check the network bandwidth because it is to fast to see under perfmon. The second issue seems to be that most tableupdates() using views is also taking far to long. I'm not sure why this is the case but at the moment it has caused us to rewrite some code for table updates (read that to say we are using the old ways insert or replace). I just can not figure out what we are doing wrong. I keep hearing that performance is not an issue with views but we can not resolve ours.
>
>John

Maybe you have index blaot? If you rename the cdx file and open it up in SBT, SBT will reindex the file, then go into the other packages and have them do likewise. Now compare the size of the cdx files.

>When I use a view (which is basicly a select statement using a get ?custno) to get a customer record it can take about a full minute or more. What I've noticed is the bottleneck is in the network (100baseTX full duplex, switched).

Are you running the create view command and then using it? Or ust using the view? You slow response could be generating the view code inthe dbc time and time again? This will cause dbc blaot!

My throughput is what I expect and what you are telling me sounds like something is wrong. Maybe your passing the parameter to the table is the wrong size?

Best case for getting your performance is to practice via the select statement alone. When you find that the performance sucks they you have to make new indexes till your performacne is correct. I had to do this with one of my vendor supplied tables. Seems that I was expecting the index to match a common thing like custno, and found that all the cust no's indexs were compounded with another coulmn.

Once you get it right, you will have to add that index to one of the vendors index table so it will get created time and again.