[koresaram]

дело в том, что у меня есть скрипт перегоняющий любую таблицу из excel в mysql и в качестве имен полей в мускуле можно задать чтобы скрипт ставил имена столбцов екселя. то есть можно просто оставить что будут поля field1 field2 и т.п. но хочется наглядности чтоли

[Greyman]

Ну вот скриптом и переименовывай при переводе, нафига это на Excel возлагать? В нем можно выбирать либо буквы, либо цифры. Так же ты можешь модифицировать скрипт, чтобы брать в качестве наименований значения в первой строке (как делает тот же офис при слиянии, например).

[koresaram]

тут немаловажный вопрос в том, что я в скрипте не понимаю нифига поэтому я и решил пойти в обход то бишь переименовать в екселе столбцы

а он позволяет брать первую строку в качестве имен полей но при этом бабахает имена полей в базу тоже

вобщем итог: нельзя

[Gerdewski]

Скорее всего нужно не A,B,C,D,... переименовывать , а в самом поле в первой строке области таблицы дать нужные имена. В случае koresaram - Column1, Column2 и т.д. Например DBF-файлы именно так и конвертируются.

[Greyman]

Gerdewski

Так же ты можешь модифицировать скрипт, чтобы брать в качестве наименований значения в первой строке (как делает тот же офис при слиянии, например).

Я уже об этом сказал. koresaram же ссылается на то, что использует уже готовый скрипт, который не знает как поправить...

[maxo]

Greyman,
там дело точно не в сортировке, и вообще не так как я описывал - там одни цифры во всех столбцах, и надо их сопоставить. Этим ничего не становится понятным, скорее наоборот. Сегодня инет там барахлил, завтра постараюсь полжить список сюда, просто до смерти интересно что там происходит.

Pliomera способ конечно хороший, наверно так лучше и грамотнее что-ли, но я не пишу процедуры и не хочу связываться на сейчас, а главное - все это делается (должен делаться) средствами экссел, и действительно интересна сама причина; еслиб не это, можно было вообще руками подправить - их там всего несколько штук.

[maxo]

Вот и файл. К данным из первого столбца сопоставляются соответствующий из третьего и пишутся во вторую. Если в третый столбец (он сортирован по возрастанию) не найдется соответствующая запись, во вторую должен записываться ближайший сверху. Так и есть во всех ячейках, кроме окрашенных в желтый цвет - там адрес последней ячейки "эталонного" списка если больше некоторой величины, почему-то формула пишет содержимое этой самой последней ячейки.

Спасибо заранее если кто заинтересуется.

[Gerdewski]

maxo, для твоей функции данные массива должны быть отсортированы по возрастанию.
А у тебя с е5767 до конца стоят нули.
Или поменяй диапазон на e1:e5766, или отсортируй свой диапазон по возрастанию.
Все заработает.

[Greyman]

maxo
Как я и говорил, проблема с сортировкой, что также озвучил и Gerdewski. Если отсортируешь или зделаешь нормальный диапазон, то работать будет... Однако обрати внимание на строку №45. Такого значения в массиве поиска нет и твой вариант будет выдавать ближайшее, которое найдет. Т. е. в твоем варианте формулы, если где-то допущена ошибка в ФИО (я про начало темы), то ты этого так и не заметишь.

Гораздо правильнее использовать функцию "ВПР", как я и говорил. В случае поиска точного значения (последний параметр - ЛОЖЬ) массив вообще может не сортироваться, а если точного значения в нем не найдется, то формула покажет ошибку. Для твоего примера аналог используемой тобой функции будет:

Код:

=ВПР(A2;$E$1:$E$5980;1;0)

[maxo]

Нет ребята, дело не в этом - Вы обратите внимание: если в В19 записать =LOOKUP(A20;$E$1:$E$5952), то формула работает, а если =LOOKUP(A20;$E$1:$E$5953), тогда нет. В то же время эта "критическая" ячейка 5953 ничем не примечательна, то что там другие (ненулевые) цифры начинаются, это я сам ставил для пробы.
Кроме того, в предыдущей ячейке формула работает, каково бы не было это число.
Вот над этим бются теперь около 5 человек , вчера даже в skype разбирали.

Gerdewski,

должны быть отсортированы по возрастанию. А у тебя с е5767 до конца стоят нули.

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

Greyman

Однако обрати внимание на строку №45. Такого значения в массиве поиска нет и твой вариант будет выдавать ближайшее, которое найдет. Т. е. в твоем варианте формулы, если где-то допущена ошибка в ФИО (я про начало темы), то ты этого так и не заметишь

Greyman, правильно - так должно быть, но ведь на самом деле пишет не ближайшую, а то, что написано в ячейку с "критическим" адресом.

если где-то допущена ошибка в ФИО (я про начало темы), то ты этого так и не заметишь.

Это тоже правильно, а заметят это формулы в другом месте, потому и исползуется Lookup. Если б формула при ненахождении выдавала ошибку (как это сделал бы VLOOKUP - ВПР, т е вертикальный просмотр, который используется, когда задан не один столбец, а арея из нескольких, и надо решать вертикально просмотреть эту ареу (или арею))), т е по столбцам, или горизонтально. А если только один столбец или одна строка, там ведь и решать нечего) , его было бы труднее обработать, чем сравнить двух ячеек. Вообще эти списки - часть большой довольно сложной таблицы, а меня типа консультанта пригласили из-за некоторых проблем. Проблемы те уже решены, а этот вопрос так и остаетса для меня, хотя там все уже исправил путем подгона диапазона.

Вообще мне не нравится когда такие вещи делаются в эксел - он хорош для обработки уже законченной таблицы или списка, а для "живых", куда постаянно добавляются новые данные, могут создаваться проблемы, но эта таблица уже сделана, с репортами и разными наворотками, и сделать заново все это - я лучше в отпуск


Pliomera
Твой "скрипт" работает действително гарантированно, но действительно жутко медленно. Я циклы поменял местами, но от этого он быстрее не стал. Нелзя его как-то ускорить? и на что там так много времени уходит - выборка ячейки, сравнение - что-нибудь известно о том, какой процесс более прожорлив?
Или может что-нибудь типа WHILE не отыщется в VB?
И плз большая просьба - как сделать так, чтоб при обнаружении соответствии (и печати ячейки) iCount сразу наращивался, а не бежал зря до конца списка (одинаковых будем считать что не будет), ато ничего умнее кроме как ставить метку в голову старого ассемблерщика не приходит