Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP & MySQL
Message
From
01/12/2000 12:04:38
 
 
To
30/11/2000 15:56:16
General information
Forum:
Visual FoxPro
Category:
Client/server
Title:
Miscellaneous
Thread ID:
00447415
Message ID:
00448144
Views:
9
Hello, Eric

Thanks again for solving my problem.

I've digged a little bit further, and now I'm positive that this is an ODBC driver problem, because it seems to deliver to VFP incomplete information. This is what I've found:

Suppose that I define a table in back-end database. Then I need to define a view (simple, ordinary view).

Assuming the backend table have the following structure:
ID      INT(10)
NAME    CHAR(25)
B_DATE  DATE
The view can be defined and saved, but cannot be executed, because it returns an error mesage ("Invalid type property" or something, I can't remember exactly right now). Taking a closer look to the view, I've seen a very strange thing: the width of the view fields is not the same as the table fields. Something like that:
ID      INT(4)
NAME    CHARACTER(1)
B_DATE  DATE
Now, every time I need to modify the base table, I need to modify all the views based on it. And for every view I am forced to specify again and again the width for fields.

Not to mention that I can't define character fields larger than 20 characters (however, if I define a character(50) field, the view designer replace the 50 written by me with 20 - always 20, but if I save the view right now, I can enter 50 characters in the view's field and the base table is updated correctly). Thus, every time I modify the base table, I am forced to specify the widths of every numeric or character field. This is very frustrating, because it drops my efficiency.

Very strange behaviour. You know, it's a shame, because the Linux stuff it's free (er, almost). Not to mention that MySQL is lightning fast (way faster than MS SQL Server). I can prove this, but I don't want to start an argue about this issue. But for every plus there are a minus somewhere else: MySQL don't know anything about stored procedures and transactions, but there are workarounds. I'm sure that you know much better than me how to implement this... :)

I've learned a very important lesson from all this story: Almost everybody blames Microsoft for higher prices for their tools. But a handfull of guys high payed will do a much better work than a lot of people for free....

Hope I was coherent,
Thank you again, Eric.

Grigore Dolghin
Grigore Dolghin
Class Software.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform