Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Scrolling and moving two tables at the same time
Message
From
10/11/2004 10:06:36
 
 
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 8 SP1
OS:
Windows '98
Network:
Novell 6.x
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00959374
Message ID:
00959992
Views:
9
>>>Terry
>>
>>OK, so I created a view. One table is tiny, but the other is rather large as most of our tables are. When I browse the created view, it runs a query for about a minute or so then pops up. Is that what would happen if I used the view in a form? would it really take all that time to query each one? If so, that is way to slow and inefficient for us to use that method with our large tables.
>
>Kevin
>
>This sounds disappointing. My views have never taken that long. Have you checked the efficiency of the SQL statement that's built up in the View Designer? Have you tried it as the source to your grid yet? The thing that intrigues me is how else you'd get data from more than 1 table in a grid, without using a view. Anyone else out there enlighten me as I'm keen to learn how.
>
>Unless you have 2 grids - one showing the parent data and the other showing the child data, alongside.
>
>Terry

Terry,

The little test I ran was just thowing in a few fields from the main table and the one linked from the small (lookup) table.

I am not surprised I got the response on getting data from two seperate tables into a grid because some other people have asked me how I did that. Two grids beside one another would not work either because the child grid still would not display the correct value during scrolling the parent one. The problem is scrolling with the record pointer staying in the same place. All I need to do is figure out how to sync the record pointer in the table with the position displayed in the grid or a certain column in it when scrolling up or down.
``` Appreciate a normal day, it is always better than a bad one ```

Kev
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform