>Antonio Carlos,
>
>Antonio Carlos,
>
>Why do you not go and ask the VB guys? This extract is from a FAQ (see
>http://home.sol.no/jansh/vb/vb_e.htm#F). (Hope this is legal! :)). I particularily liked the part where they talk about complex queries! And how do you like their response times? 30 hours on a single table? Of course if they are working on XT's ...
>
>Quote
>
>How can I speed up my VB database application?
>
>One word: stored queries. Failing that, recordsets.
>
>KB article Q109830 gives some hints. Things you should do include:
>
> Use Snapshots when possible.
> Use transactions whenever possible.
> Use Dynasets when possible.
> Use SQL action queries when possible.
> [George Tatge (gat@csn.org)]
>
>KB article Q120172 gives additional ideas on speeding up VB database
>access
>
>Major Weakness: SQL is SLOW! A hand-coded search (with indices) is MUCH
>faster than an equivalent SQL call, especially
>with complex search criteria. For example:
>
> SELECT * FROM Table WHERE SSN = '555-33-1234' AND Posted #01-31-95#
>
>is a lot slower than:
>
> Table.Index = "SSN"
> Table.Seek "=", "555-33-1234"
> If Not Table.NoMatch Then
> While Not Table.EOF
>
> If Table("SSN") "555-33-1234" Then
> Table.MoveLast 'Forces an EOF
> ElseIf Table("Posted") #01-31-95# Then
> 'Do something
> End If
> Table.MoveNext
>
> Wend
> End If
>
>Granted, it is a LOT more code, but I ran a VERY similar query that took
>THIRTY HOURS! The equivalent hand-written
>code took ELEVEN MINUTES! That's 163 times faster! I think basically SQL
>isn't very good at figuring out which indexes to
>use (I also think I've read something to the effect that the newer
>version, 2.0 or 2.5, IS better at this).
>[John McGuire ]
>
>UnQuote
>
>If after that you are still considering VB for database applications ...
>
>Marc

I guess it's not a SQL problem. It's going to be a problem of a programmer, because the average level of VB-people is much lower, just because there is influx of them on market.

Edward Pikman
Independent Consultant