именно `field` = `field` + '$value - не может. Транзакции имеют явный конфликт ресурсов и будут сериализованы самой базой данных корректно.
innodb - на блокировке строки
myisam - блокировкой таблицы
А вот если делаете select field, дальше что-то на приложении считается, а потом update set field = newvalue - то тут проблема конкурентного доступа будет.
Итак, в чём вопрос? Почему у вас нет константы BTCinUSD? Видимо вы её не объявили либо находитесь не в том namespace. (Добавление)
Если же ваш {{ BTCinUSD }} должен обрабатывать не laravel - то этому есть отдельный раздел Blade & JavaScript Frameworks: https://laravel[dot]com/docs/5[dot]7/bla[dot][dot][dot]cript-frameworks
В отличии от прочего вопрос менее тривиален и проблема действительно может вводить в заблуждение.
Sasha777 пишет:
при попытке поставить смайлик
Проблема именно в этом.
Смайлики - это четырёхбайтовые символы utf8.
То что на данный момент отзывается на utf8 в mysql - не есть utf8, а лишь неполная реализация, максимум 3 байта на символ.
Для обработки смайликов в mysql вы должны использовать кодировку соединения и полей utf8mb4
2 и 3 варианты очевидно пожалуются на несуществующего пользователя php5.4
4 и 5 - вероятно указывают не на директорию
1 - проверьте права на запуск скрипта и является ли он самодостаточным скриптом, т.е. начинается с [url=https://en.wikipedia.org/wiki/Shebang_(Unix)]shebang[/url]
Задача проста - в зависимости от нажатой кнопкой содержащей метод POST - вернуть нужную часть кода в запрос. Я решил промаркировать индексами от 0 до 5 и сохранять в сесии, тк есть пагинация.
Зачем вам для этого функция?
Почему функция для этого носит абсолютно бессмысленное название?
Сохранять сортировку и прочие вещи пагинации в сессию - идея очень неудобная. Открыл две вкладки - и они живут своей жизнью. Ссылку не переслать. Это дико неудобно именно для использования. Равно как и использовать для этого POST. Используйте нормальный GET
Почему число? Почему бессмысленное наименование Ul_params? params - для одного литерала? Даже не bitmask ведь.
Почему разные name с формы? Обычно направления сортировки - это value заранее заданного name, к примеру sort=PriceUP. Соответственно маппится на выражение сортировки элементарным поиском по ключу массива.
Выбросить эту функцию. Посмотреть, где она использовалась. Понять зачем она там использовалась. Подумать, что в том коде делается. И придумать, как эту задачу выполнить без странного кода.
Поддержка 5.6. Не 5.х.
А поддержка последней ветки где был register_globals - уже 5 лет прошло. И все 10 с тех пор как register_globals объявлены готовящимися к удалению.
Распилить на две таблицы не поможет совершенно ничем.
Вопрос только в том, что переформатировать результат в нужном для этой задаче виде банально проще и удобнее в коде приложения, а с базы вычитать просто список пользователь, дата, значение. Чем требовать от базы динамическое число полей для чего строго типизированный SQL удобен чуть менее чем никак.
Называется pivot.
На заведомо известной ширине таблицы запросом сделать можно, но никто не будет рад _это_ потом видеть.
Переформатируйте на приложении. Можно в двумерный массив, а можно и в один проход вывести если известны минимальная-максимальная даты и множество запросить отсортированным по order by name, date
это? Никуда. Так делать не надо уже очень давно. Лет, наверное, 20 как.
В месте регистрации с паролем делаете password_hash
Для проверки корректности пароля - password_verify. Ну и password_needs_rehash тут же сразу, чтобы потом не возвращаться.
Где эти места в коде - знает тот, кто у вас делал авторизацию.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11869
