Stored Procedure with VB is very slow

Which the way easiest to use Stored Procedure with VB? I am using a Stored Procedure that comes back available schedules in certain date. To carry the first schedules and to bring in the screen, it is being long five seconds, it is a very big time evaluating that several people will be working at the same time and marking schedules in the calendar schedules. If the user changes the date it is more 5 seconds. We asked the one consultant and him he said that was even so, because INFORMIX doesn't get a result set to come back everything at once, because he only gets data that are in a cursor to come back. I thought about not coming back the schedules of every time, but to accumulate a certain amount for later to come back. Example 07:00 07:30 07:30 08:00 08:00 08:30 etc Instead of each line of this to come back, I thought about connecting these schedules in a variable nchar or varchar, and later to come back: Example: 07:00-07:30;07:30-08:00;08:00-08:30 and later to come back, the data would be treated inside of the source of VB, but I don't know how to implement this in Stored Procedure, I don't know as connecting like this the schedules. If somebody has some idea I thank I am In advance grateful mail-me marcelo_velasque@hotmail.com

Mutley wrote: > Which the way easiest to use Stored Procedure with VB? > > I am using a Stored Procedure that comes back available schedules in certain > date. To carry the first schedules and to bring in the screen, it is being > long five seconds, it is a very big time evaluating that several people will > be working at the same time and marking schedules in the calendar schedules. > If the user changes the date it is more 5 seconds. We asked the one > consultant and him he said that was even so, because INFORMIX doesn't get a > result set to come back everything at once, because he only gets data that > are in a cursor to come back. > I thought about not coming back the schedules of every time, but to > accumulate a certain amount for later to come back. Example > 07:00 07:30 > 07:30 08:00 > 08:00 08:30 > etc > Instead of each line of this to come back, I thought about connecting > these schedules in a variable nchar or varchar, and later to come back: > Example: 07:00-07:30;07:30-08:00;08:00-08:30 > and later to come back, the data would be treated inside of the source of > VB, but I don't know how to implement this in Stored Procedure, I don't know > as connecting like this the schedules. I do not think that this plan is a very good idea at all. Your Stored Proc. (SP) will still need a cursor to create this string . You could have problems if the string is too large (max 255 char). And you will have additional work in your VB application. You need to first figure out why your SP is slow. Try running it outside your VB application (dbaccess, SQLEditor) and evaluate its performance (take the help of your ever-willing Informix DBA!). Once your have tuned your SP, if the problem remains, examine other components (network, VB app) to figure out the weak link in your chain. Fundamentally, using SPs to return data is nothing unusual - there are tons of sites that use them extensively. Rudy