Рекомендации для Visual Studio 2 010 решений, которые содержат и 'Любой ЦП' и 'x86' проекты
Если ваш столбец определен как INT, то MySQL также попытается преобразовать строку сравнения в целое число. Поскольку он начинается с числа, MySQL извлечет все начальные цифры из строки (в данном случае 19), преобразует ее в INT и затем выполняет сравнение. Следовательно, вы получите строки с возвращенным sn = 19. Например:
SELECT 19 = '19c5bx'
Вывести
1 -- true
Чтобы обойти это, CAST любые целочисленные столбцы как CHAR перед сравнением, например
SELECT CAST(19 AS CHAR) = '19c5bx'
Выходные данные
0 -- false
Это все равно будет работать нормально, если вы хотите сравнить с целым числом вместо строки, например,
SELECT CAST(19 AS CHAR) = 19
Вывод
1
Так что-то вроде этого должно работать (приведите другие столбцы как CHAR, если они также INT в вашей таблице):
$query_details= "SELECT *
FROM Purchases
WHERE CAST(sn AS CHAR) = '$phone'
OR sentto = '$phone'
OR batch= '$phone' ";
4 ответа
Имея больше опыта в этом, вот что я сейчас думаю:
- Не имеет никакого значения, как называется платформа решения для проекта со смешанной платформой. Поведение VS точно такое же, требующее такой же степени очистки после добавления проекта.
- «Смешанные платформы» немного более точны, поэтому я немного предпочитаю эту.
Изменение всего на x86 нежелательно по двум причинам:
- Некоторые алгоритмы почти в два раза быстрее в режиме x64 .
- Любая общая библиотека x86 не может быть использована в проекте, который выигрывает от режима x64.
- Поддержание разделяемых библиотек на двух платформах, x86 + x64, требует гораздо больше усилий, чем сохранение их на уровне «Любой ЦП» и очистка после Visual Studio каждый раз, когда он сбрасывает нежелательные конфигурации решения в решение.
Я настроил только свое стартовое приложение Windows Forms как «x86», а все библиотеки классов в проекте - как AnyCPU. Если я выполню приложение, все неуправляемые зависимости, даже из библиотек классов x86, по-прежнему будут работать.
Теперь, если я добавлю библиотеку классов, которая не имеет x86-зависимостей из моего проекта, в другое приложение, настроенное как AnyCPU, оно будет работать "из коробки".
До того, как я это сделал, все мои библиотеки, где x86 и я, получали исключение, если я хотел использовать их в 64-битном проекте.
С моей точки зрения, это лучшее решение.
Да, это небольшая неприятность, в которую вы попадете, если позволите конвертеру проектов VS2010 импортировать проект из предыдущей версии. А кто этого не делает. Старые IDE использовали Debug|Any CPU и Release|Any CPU в качестве имен конфигурации по умолчанию. VS2010 действительно предпочитает устанавливать Platform Target на x86, потому что IDE работает намного лучше, когда вы это делаете. И использует Debug|x86 и Release|x86 в качестве имен конфигурации по умолчанию.
Что приводит к путанице при импорте старого проекта. И дополнительный набор конфигураций (смешанные платформы), о котором вы не просили, чтобы справиться с этим беспорядком. Фу. Удалить их тоже нельзя, кнопка Remove в Configuration Manager отключена.
Это просто названия btw, которые на самом деле не являются репрезентативными для настройки Platform Target. Вы можете изменить настройку, но это не изменит волшебным образом имя конфигурации. Фу.
Вы не можете исправить это в IDE. Вам придется редактировать файлы .sln и .vcproj, чтобы избавиться от лишних конфигураций и изменить имена тех, которые вы хотите сохранить. Или просто сохраните "Mixed Platforms" в качестве конфигурации по умолчанию и игнорируйте остальные. Просто установите Platform Target на то, что вам нужно, это не обязательно должно совпадать с именем конфигурации.
Ad Примечание 2: Да. Solution platform - это только название для набора конфигураций проекта, включая то, собирать или нет конкретный проект.
Я лично использую x86 для всех настольных приложений (настольных, потому что они развертываются на машинах конечных пользователей, которые вы обычно мало контролируете - это гораздо проще, если вы развертываете серверное приложение на известном сервере).
Причины:
- x86 позволяет легче отлаживать - редактирование и продолжение не поддерживается при работе в 64-битном режиме.
- Никогда нельзя предугадать, когда в будущем вы добавите ссылку на сборку, требующую x86, и забудете правильно протестировать ее на 64 битах, что приведет к досадным ошибкам во время выполнения 64-битных развертываний.