Если ты задаешься таким вопросом, то у тебя структура базы неверная.
Выкладывай описания таблиц и их структуры.

А по вопросу, как вариант:

$row = mysql_fetch_array($result , MYSQL_NUM);
$feld_count = count($row);

Хотя, извини, но это бред чистой воды.
Ты программист, ты архитектор базы. ТЫ ЧТО, НЕ ЗНАЕШЬ, СКОЛЬКО ПОЛЕЙ В ТВОИХ ТАБЛИЦАХ???
Или ты их (поля) динамически создаешь?

Поля создаются динамически.
Вкратце, допустим следующая ситуация:
Есть турнир по какой-нибудь киберспортивной дисциплине. У определенного игрока может быть 3, а может быть и 10 матчей. В связи с этим создаются поля:
round_1|round_2 e.t.c
Т.е мне изначально известно лишь максимально возможное количество полей, но точного их количества не известно. Я не хочу отталкиваться от проверки на максимально возможное количество полей в цикле так как считаю это неверным подходом к решению ситуации.

у тебя не верный подход к архитектуре бд.К примеру можешь хранить матчи в другой таблице.А у игрока при изменении выставлять количество матчей.

Placido
Плохой совет.
Во-первых, information_schema зачастую недоступна у хосеров.
Во-вторых, ТС незачем туда соваться, с егог отношением к DB

NierRa
Вечером сделаем.

Благодарю

Placido
Я и не говорю, что ответ плохой. Я говорю, что совет плохой Нельзя детям спички в руки давать Он же тудыть поди еще и под root полезет.
А сам ответ отличный, и есть множество задач, где именно так и надо делать.

NierRa
Обещанное:
Как уже многие выше высказались, данная структура DB неправильная. Делать так нельзя.
На самом деле делать так можно (имеем возможность, что ты и сделал), но это непраильно.
Можно было бы просто указать, как правильно, но этот путь не для нас :)
Главное не ЗНАТЬ, как правильно, а ПОНИМАТЬ, почему именно так правильно.
Тогда и на других проектах ты уже спинным мозгом будешь это чувствовать.

Теория:
Читаем про нормальные формы таблиц.
Если с первого раза не понятно, читаем второй раз. Третий. Читаем весь день, пока не врубимся.
Это потом даст экономию многих часов в разработке DB.

Практика:
У тебя имеется таблица игроков, куда ты, в качестве полей добавляешь так же турниры (round_n)
У первого игрока был только 1 турнир.
У второго 3.
У еще 100 следующих не более 5ти.

Игрок 104 оказался супер-мега геймером и он прошел аж 10 турниров.
И теперь у нас в таблице есть столбцы round_1 ... round_10
Причем, они есть для всех записей (для всех игроков). А нужны ли они для предыдущих 100 игроков??? Нет. Но они будут тащиться по всей таблице.
И, предположем, что у тебя не будет больше таких супер-мега игроков. Но, для каждого вновь прибывшего, всё равно будут в таблице эти ненужные для них поля.

Это увеличивает размер базы, накладные расходы на обслуживание базы, нагрузку на физический сервер. Потом хостер тебя закроет, т.к. ты мешаешь соседям.

Вот поэтому так делать не нужно.

А делаем так:

таблица users
u_di; // id юзера
u_name; // имя юзера
..... // прочее

Таблица rounds
r_id; // первичный индекс
u_id; // id юзера, который сыграл раунд 
r_num; // номер раунда, который сыграл юзер с id = u_id

Таким образом мы имеем таблицу, в которой для каждого игрока присутствуют только те раунды, которые он действительно отыграл.

И в скрипте ты имеешь:

$query = "SELECT * FROM `users` LEFT JOIN `rounds` ON (`users`.`u_id` = `rounds`.`u_id`) WHERE `users`.`u_id` = " . $u_id;

На выходе все данные об игроке + все раунды, которые он отыграл.
Запрос тестовый, чтобы просто показать результат. Лучше все запросы сначала смотри в phpMyAdmin, тогда будет ясно, какие поля в результате выводятся.
В приведенном мною примере в каждой строке будут повторяться данные об игроке, что тоже не совсем красиво. Но это тебе уже пища для размышления.