Cita: No todos los autos tienen solo 15 fotos
Eso se entiende perfectamente, pero esto:
Código SQL:
Ver originalSELECT FotId, FotUrl, FotUrl2, FotUrl3, FotUrl4, FotUrl5, FotUrl6, FotUrl7, FotUrl8, FotUrl9,
FotUrl10, FotUrl11, FotUrl12, FotUrl13, FotUrl14, FotUrl15
FROM tblfoto
WHERE AutId = $selected_val
Muestra que tienes una tabla espantosamente diseñada, que no sólo no te sirve para hacer bien las cosas, sino que te causa problemas aa la hora de intentarlo...
Esa "cosa" que tienes por tabla de foros, está MAL. Ni siquiera respeta el modelo E-R de BBDD, y es la raiz de todo el asunto...
Es un defecto de diseño de datos muy habitual en los principiantes, y te comento que si la rediseñaras, sería muchísimo más sencillo.
Para decirlo en pocas palabras: Si no todos los autos tienen 15 foros, entonces no puedes ni debes crear una tabla con 15 campos para las fotos. Eso no es correcto. Lo que debes hacer es una tabla que tenga una relación 1:N con los autos, tal que haya de cero a N fotos diferentes en diferentes registros, relacionadas con el auto, cada una de ellas a su vez con su propio identificador.
Si lo planteases así, la consulta sería por ejemplo:
Código SQL:
Ver originalSELECT AutId, IdFoto, FotUrl
FROM tblfoto WHERE AutId = $selected_val
Lo que te devolveria un array de 0 a 15 fotos (e incluso podrías poner muchas mas sin causar problemas), que puedes recorrer en forma anidada, y puede construirse en forma dinámica.
Pero tal como lo tienes, tendrás que hardcodear la estructura de 5x3, con uso de if() para validar si existe o no URL en el campo que aplica.
La verdad, creo que modificar esa cosa que usas de tabla e un trabajo más simple.
Pero, bueno, es tu decisión... ¿Qué quieres hacer? ¿Corriges ese diseño defectuoso, o quieres seguir con lo que tienes y sufrir cada vez que necesites hacer algo con las fotos?