>
>WOW! You must be running a MONSTER of a network to get that kind of performance. 64-bit maybe? Maybe not.
>
>Although, on further consideration, I've often found that once the connection is established, ODBC performance is pretty good, even with Sybase. I just wish it didn't take as long to establish a connection, particularly with views. Why don't the views that call the same database use the same connection? I wrote an app last year where I created my own 'views' (which weren't updateable) that all used the same connection in order to improve on connection time. Anyone find a better way?


By default, the views do not share the same connection (although they are defined using the same connection!). I had to make sure that all views were marked to share the same connection. This was exceedingly necessary when using manual transactions and commit or rollback on the tableupdates. I even had to make sure the SQL passthrough was mapped to the same connection as the views so I could save all data with one transaction. When I had one view that did not share the connection, it caused the saves to lock up because the user ending up blocking themselves becaus the save was using multiple connections.

Now consider this situation: You are in a manual transaction (doing a commit only if all saved data goes through fine) and issue a tableupdate, which returns True. However, because of some other problem, maybe some bad data or whatever, you cannot commit your data at this time and must rollback, sending the user back to edit. They make their change and try to save again. This time, everything is okay and the commit is done. However, some of your data was NEVER SAVED!

Why? The original tableupdate thought it worked and the data was saved to the database. Now the table is marked as having all current data. Because you did a rollback, the updates that the Tableupdate issued, were never actually saved to the database. When you issue save again, the tableupdate that occurs the second time HAS NOTHING TO UPDATE as far as it is concerned. It does nothing!

So here is what I have discovered you must do if using COMMIT and ROLLBACK in manual transaction mode.

If you have issued any tableupdates and then determine that a ROLLBACK must occur (suppose a different tableupdate fails) You must reload all data even if this means wiping out edited data because there is no way of knowing what edits were done and not really saved (even though the system thought they were saved!)

What we were originally doing in our save method was validating the data for each table and issuing the tableupdate if everything was okay. If, at the end, there was some invalid data, we advised the user and stayed in edit. They fixed the data and we saved again. It was not so easy at the time trying to figure out why some data saved some of the time and not others!