>Io lo so che sei un mostro !!!!!
>Il fatto è che sono 20 anni che non tocco più le funzioni trigonometriche
>e mi ero rassegnato a ristudiarmele. Grazie di cuore !

Yes, but after this you'll have a much larger problem - and that's the numbering of the seats, and a table where to keep the sold/reserved/nonexistent/free seat status of each seat, multiplied by showdate (one set of records for each show) etc etc.

My bet is that you'd better calculate the screen coordinates of each seat once, store them in some seat.dbf, and then in your tickets/reservations table have a foreign key into seat.dbf.

You'll also find that the real seats may not be as regular as you think - the width of the aisle (the corridor) is more or less the same for each row of seats, which means that its angle, as measured from the center, is smaller and smaller as we move away from the center. Also, this width is not the same for each row. Furthermore, the seats are almost always staggered, i.e. when you sit, you don't have someone's head right in front of you, you're looking between two heads. So your geometrical approach will only be an approximation of the actual seats. IOW, you may need a new set of parameters for each row - the angle of each seat in that row, the starting angle, the radius.

In the end, it really doesn't matter whether your graphic representation of the seats is accurate. They only have to visually match what's on the map - so whoever is viewing them can get oriented. Your form needs to be only a crude representation of the actual seats. You don't even have to rotate them properly - just line them so that they visually represent the real layout close enough.

BTW, I've seen code which was selling tickets like that in a few movie theaters in Belgrade in 1990... they had a pretty crude map of the room, and the seats were sold using a joystick. On a Commodore 64. And it printed the tickets.