Как обойти ошибку Too many Sections при сборке?
Пытаюсь сделать программу программу для численного интегрирования, для ввода формулы мною используется библиотека exprtk, которая является header-only и занимает 37k строк.
Под Mac Os и Linux, всё запускалось нормально, стоило запустится на windows.
Как обойти эту ошибку?
Пытался в pro файл при помощи QMAKE_CXX_FLAGS флаги wa,-mbig-obj прикрутить, пытался их по разному прикрутить, компилятор не знает таких флагов.
Сама ошибка
C:/Qt/Qt5.8.0/Tools/mingw530_32/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/as.exe: debug\func.o: too many sections (65238)
: Fatal error: can’t close debug\func.o: File too big
Makefile.Debug:667: recipe for target ‘debug/func.o’ failed
mingw32-make[1]: Leaving directory ‘C:/Users/1/Desktop/OOPcurse/build-Integrator-Desktop_Qt_5_8_0_MinGW_32bit-Debug’
mingw32-make[1]: *** [debug/func.o] Error 1
Makefile:34: recipe for target ‘debug’ failed
mingw32-make: *** [debug] Error 2
23:45:15: Процесс «C:\Qt\Qt5.8.0\Tools\mingw530_32\bin\mingw32-make.exe» завершился с кодом 2.
Ошибка при сборке/установке проекта Integrator (комплект: Desktop Qt 5.8.0 MinGW 32bit)
Во время выполнения этапа «Сборка»
23:45:15: Прошло времени: 01:50.
- Вопрос задан более трёх лет назад
- 920 просмотров
Обрабатываем ошибки в React: полное руководство
Все хотят писать производительные, функциональные и при этом стабильные приложения. Но так как всем людям свойственно ошибаться, кода без ошибок не бывает. Независимо от уровня внимательности и количества написанных тестов всегда что-то может пойти не так. Поэтому с точки зрения пользовательского опыта важно предсказать появление проблемы, локализовать и устранить ее.
Рассмотрим обработку ошибок в React: что делать при их появлении, как их выявить и устранить.
Почему нужно находить ошибки в React
Начиная с 16-й версии React, возникающая во время жизненного цикла ошибка приводит к размонтированию всего приложения, если его не остановить. Ранее компоненты сохранялись на экране, даже если были искажены и не функционировали должным образом. Теперь уничтожить страницу полностью и отобразить пустой экран может досадная необнаруженная ошибка в незначительной части пользовательского интерфейса или даже в неконтролируемой разработчиком внешней библиотеке.
Выявление ошибок в JavaScript
В обычном JavaScript для выявления ошибок есть довольно простые инструменты. Например, оператор try/catch : попытаться ( try ) что-то выполнить, а если не получится, то поймать ( catch ) ошибку и сделать что-нибудь, чтобы минимизировать ее последствия.
try // некорректная операция может вызвать ошибку
doSomething();
> catch (e) // если ошибка произошла, ловим ее и делаем что-нибудь без остановки приложения,
// например отправляем ее в службу регистрации
>
Для функции async синтаксис будет такой же:
try await fetch('/bla-bla');
> catch (e) // Выборка не удалась! С этим нужно что-то делать!
>
Для традиционных промисов есть метод catch . Предыдущий пример fetch с API на основе промиса можно переписать так:
fetch('/bla-bla').then((result) => // Если промис выполнен успешно, результат будет здесь,
// с ним можно сделать что-нибудь полезное
>).catch((e) => // О нет, выборка не удалась! Нужно что-то с этим сделать!
>)
Это та же концепция, только немного другая реализация, поэтому и далее для всех ошибок используем синтаксис try/catch .
Простой try/catch в React: как правильно его выполнить
С пойманной ошибкой нужно что-то делать кроме того, чтобы записать ее куда-нибудь. Иначе говоря, что можно сделать, чтобы упростить жизнь пользователю? Не стоит оставлять его с пустым экраном или неработающим интерфейсом.
Наиболее очевидным и интуитивно понятным решением будет рендеринг на экране чего-либо до исправления ситуации. К счастью, оператор catch предоставляет для этого ряд возможностей, включая установку состояния. Например:
const SomeComponent = () => const [hasError, setHasError] = useState(false);
useEffect(() => try // делаем что-либо, например выборку данных
> catch(e) // выборка не прошла, данных для рендеринга нет!
setHasError(true);
>
>)
// что-то произошло во время выборки, отобразим красивый экран с ошибкой
if (hasError) return
// данные есть - отрендерим их
return /
Мы пытаемся отправить запрос на выборку данных. В случае неудачи устанавливаем состояние ошибки и, если оно равно true , отображаем экран ошибки с дополнительной информацией для пользователя, например номером службы поддержки.
Этот способ подходит для простых, предсказуемых и ограниченных вариантов использования, таких как обнаружение неудачного запроса fetch .
Но если вы захотите отловить все возможные варианты ошибок в компоненте, то столкнетесь с определенными проблемами и серьезными ограничениями.
Ограничение 1: проблемы с хуком useEffect
Если просто обернуть useEffect с помощью try/catch , это не сработает:
try useEffect(() => throw new Error('Hulk smash!');
>, [])
> catch(e) // useEffect выбрасывается, но не вызывается
>
Дело в том, что useEffect вызывается асинхронно после рендеринга, поэтому для try/catch все проходит успешно. Подобное происходит и с любым Promise: если не ожидать результата, JavaScript просто продолжит свое дело, вернется к нему, когда промис будет выполнен, и выполнит только то, что находится внутри useEffect (и затем промиса). Выполненный блок try/catch исчезнет к тому времени.
Чтобы отлавливать ошибки внутри useEffect , нужно также поместить try/catch внутрь:
useEffect(() => try throw new Error('Hulk smash!');
> catch(e) // эта ошибка будет перехвачена
>
>, [])
Поэкспериментируйте с этим примером.
Это относится к любому хуку, использующему useEffect , и ко всем асинхронным действиям. В результате вместо одного try/catch , обертывающего все, придется разбить его на несколько блоков: по одному на каждый хук.
Ограничение 2: дочерние компоненты
try/catch не сможет поймать ошибку внутри дочерних компонентов. Например:
const Component = () => let child;
try child =
> catch(e) // бесполезен для отлова ошибок внутри дочернего компонента, не будет запускаться
>
return child;
>
const Component = () => try return
> catch(e) // по-прежнему бесполезен для обнаружения ошибок внутри дочернего компонента, не будет запускаться
>
>
Убедитесь на этом примере.
После Child /> нет реального рендеринга компонента. Мы создаем Element компонента, который является его определением. Это просто объект, который содержит необходимую информацию, такую как тип компонента и реквизиты, которые позже будут использоваться самим React, что фактически и вызовет рендеринг этого компонента. И произойдет это после успешного выполнения блока try/catch . Та же ситуация, что с промисами и хуком useEffect .
Ограничение 3: нельзя установить состояние во время рендеринга
Если попытаться отловить ошибки вне useEffect и различных обратных вызовов (т. е. во время рендеринга компонента), то разобраться с ними должным образом уже не так просто: обновления состояния во время рендеринга не допускаются.
Вот пример простого кода, который вызовет бесконечный цикл повторных рендеров, если произойдет ошибка:
const Component = () => const [hasError, setHasError] = useState(false);
try doSomethingComplicated();
> catch(e) // недопустимый вариант! В случае ошибки вызовет бесконечный цикл
// см. реальный пример в codesandbox ниже
setHasError(true);
>
>
Конечно, можно просто отобразить экран ошибки вместо установки состояния:
const Component = () => try doSomethingComplicated();
> catch(e) // допустимый вариант
return
>
>
Но это немного громоздко и заставит по-разному обрабатывать ошибки в одном и том же компоненте: состояние для useEffect и обратных вызовов, а также прямой возврат для всего остального.
// это рабочий, но громоздкий вариант, не заслуживающий внимания
const SomeComponent = () => const [hasError, setHasError] = useState(false);
useEffect(() => try // делаем что-либо, например выборку данных
> catch(e) // невозможен простой return в случае ошибок в useEffect и callbacks,
// поэтому приходится использовать состояние
setHasError(true);
>
>)
try // делаем что-либо во время рендеринга
> catch(e) // но здесь мы не можем использовать состояние, поэтому в случае ошибки нужно возвращать напрямую
return ;
>
// и все же нужен return в случае ошибки состояния
if (hasError) return
return />
>
В итоге, если в React полагаться исключительно на try/catch , то мы либо пропустим большую часть ошибок, либо превратим каждый компонент в непонятную смесь кода, которая, вероятно, сама по себе вызовет ошибки.
К счастью, есть и другой способ.
Компонент React ErrorBoundary
Обойти отмеченные выше ограничения позволяет React Error Boundaries. Это специальный API, который превращает обычный компонент в оператор try/catch в некотором роде только для декларативного кода React. Типичное использование будет примерно таким:
const Component = () => return (
)
>
Теперь, если в этих компонентах или их дочерних элементах что-то пойдет не так во время рендеринга, ошибка будет обнаружена и обработана.
Но React не предоставляет компонент как таковой, а просто дает инструмент для его реализации. Простейшая реализация будет примерно такой:
class ErrorBoundary extends React.Component constructor(props) super(props);
// инициализировать состояние ошибки
this.state = < hasError: false >;
>
// если произошла ошибка, установите состояние в true
static getDerivedStateFromError(error) return < hasError: true >;
>
render() // если произошла ошибка, вернуть резервный компонент
if (this.state.hasError) return <>Oh no! Epic fail!
>
return this.props.children;
>
>
Мы создаем компонент класса regular и реализуем метод getDerivedStateFromError , который возвращает компонент в надлежащие границы ошибок.
Кроме того, при работе с ошибками важно отправить информацию о них в сервис обработки. Для этого в Error Boundary есть метод componentDidCatch :
class ErrorBoundary extends React.Component // все остальное остается прежним
componentDidCatch(error, errorInfo) // отправить информацию об ошибке
log(error, errorInfo);
>
>
После настройки границ ошибок с ними можно работать, как и с любым другим компонентом. Например, можно сделать его более пригодным для повторного использования и передать резервный вариант в качестве реквизита:
render() // если произошла ошибка, вернуть резервный компонент
if (this.state.hasError) return this.props.fallback;
>
return this.props.children;
>
Используем таким образом:
const Component = () => return (
Oh no! Do something!>>
)
>
Можно выполнять и другие задачи, например сброс состояния при нажатии кнопки, дифференциацию ошибок по типам и отправку ошибки в контекст.
Однако есть одно предостережение: улавливаются не все ошибки.
Компонент ErrorBoundary: ограничения
ErrorBoundary улавливает только те ошибки, которые возникают во время жизненного цикла React. Все происходящее за его пределами, включая разрешенные промисы, асинхронный код с setTimeout , различные обратные вызовы и обработчики событий, просто исчезнет, если не будут обработано явно.
const Component = () => useEffect(() => // будет пойман компонентом ErrorBoundary
throw new Error('Destroy everything!');
>, [])
const onClick = () => // эта ошибка просто исчезнет в void
throw new Error('Hulk smash!');
>
useEffect(() => // если это не сработает, ошибка тоже исчезнет
fetch('/bla')
>, [])
return
>
const ComponentWithBoundary = () => return (
)
>
Общей рекомендацией для ошибок такого рода является использование обычных try/catch . По крайней мере здесь мы можем более или менее безопасно использовать состояние: обратные вызовы обработчиков событий — это как раз те места, где обычно устанавливают состояние. Итак, технически можно просто объединить два подхода, например:
const Component = () => const [hasError, setHasError] = useState(false);
// большинство ошибок в этом и в дочерних компонентах будут перехвачены ErrorBoundary
const onClick = () => try // эта ошибка будет поймана catch
throw new Error('Hulk smash!');
> catch(e) setHasError(true);
>
>
if (hasError) return 'something went wrong';
return
>
const ComponentWithBoundary = () => return (
>
)
>
Мы вернулись к исходной ситуации: каждый компонент должен поддерживать свое состояние «ошибка» и, что более важно, принимать решение о том, что с ним делать.
Конечно, вместо того чтобы обрабатывать эти ошибки на уровне компонентов, можно просто передавать их до родителя, у которого есть ErrorBoundary , через пропсы или Context . Таким образом, по крайней мере можно иметь «резервный» компонент только в одном месте:
const Component = (< onError >) => const onClick = () => try throw new Error('Hulk smash!');
> catch(e) // просто вызовите пропс вместо сохранения здесь состояния
onError();
>
>
return
>
const ComponentWithBoundary = () => const [hasError, setHasError] = useState();
const fallback = "Oh no! Something went wrong";
if (hasError) return fallback;
return (
>
setHasError(true)> />
)
>
Но здесь много дополнительного кода! Так пришлось бы делать для каждого дочернего компонента в дереве рендеринга. Не говоря уже о том, что сейчас мы обрабатываем два состояния ошибки: в родительском компоненте и в самом ErrorBoundary . А у ErrorBoundary уже есть все механизмы для распространения ошибок вверх по дереву — здесь мы делаем двойную работу.
Разве нельзя просто перехватывать эти ошибки из асинхронного кода и обработчиков событий с помощью ErrorBoundary ?
Поиск асинхронных ошибок с помощью ErrorBoundary
Хитрость заключается в том, чтобы сначала поймать ошибки с помощью try/catch , затем внутри оператора catch запустить обычную повторную визуализацию React, а затем повторно отбросить эти ошибки обратно в жизненный цикл повторной визуализации. Таким образом, ErrorBoundary может перехватывать их, как и любую другую ошибку. И поскольку обновление состояния — это способ запуска повторного рендеринга, а функция установки состояния может фактически принимать функцию обновления в качестве аргумента, решение — чистая магия.
const Component = () => // создать случайное состояние, которое будем использовать для выдачи ошибок
const [state, setState] = useState();
const onClick = () => try // возникла какая-то проблема
> catch (e) // обновление состояния триггера с функцией обновления в качестве аргумента
setState(() => // повторно выдать эту ошибку в функции обновления
// будет запущено во время обновления состояния
throw e;
>)
>
>
>
Полный пример в этом codesandbox.
Последним шагом будет абстрагирование этого сокращения, поэтому нам не нужно создавать случайные состояния в каждом компоненте. Здесь можно проявить творческий подход и создать хук, который создаст генератор асинхронных ошибок:
const useThrowAsyncError = () => const [state, setState] = useState();
return (error) => setState(() => throw error)
>
>
const Component = () => const throwAsyncError = useThrowAsyncError();
useEffect(() => fetch('/bla').then().catch((e) => // выдать асинхронную ошибку здесь
throwAsyncError(e)
>)
>)
>
Или можно создать оболочку для обратных вызовов следующим образом:
const useCallbackWithErrorHandling = (callback) => const [state, setState] = useState();
return (. args) => try callback(. args);
> catch(e) setState(() => throw e);
>
>
>
const Component = () => const onClick = () => // выполнить что-либо опасное здесь
>
const onClickWithErrorHandler = useCallbackWithErrorHandling(onClick);
return
>
Или что-нибудь еще, что душе угодно и требуется приложению. Ошибки теперь не спрячутся.
Полный пример в этом codesandbox.
Можно ли использовать react-error-boundary?
Для тех, кто не любит изобретать велосипед или просто предпочитает библиотеки для уже решенных задач, есть хороший вариант, который реализует гибкий компонент ErrorBoundary и имеет несколько полезных утилит, подобных описанным выше. Это — react-error-boundary.
Использовать его или нет — вопрос личных предпочтений, стиля программирования и уникальных особенностей компонентов.
Теперь, если в приложении возникнет проблема, вы сможете легко с ней справиться.
- Блоки try/catch не будут перехватывать ошибки внутри хуков, таких как useEffect , и внутри любых дочерних компонентов.
- ErrorBoundary их перехватывать может, но не работает с ошибками в асинхронном коде и в обработчиках событий.
- Тем не менее вы можете заставить ErrorBoundary ловить их. Просто сначала их нужно поймать с помощью try/catch , а затем забросить обратно в жизненный цикл React.
- Управление состоянием в React: обзор
- 9 советов по работе с консолью JavaScript, которые помогут оптимизировать отладку
- Preact вместо ручной оптимизации React-приложения
Читайте нас в Telegram, VK и Дзен
Панель приборов Приора2 с CAN-шиной (ч .2) Установка
Так же к панели нужен подрулевой переключатель, так как обычный не функционирует с панелью.
И теперь самое главное, конечно проще и дешевле взять панель приборов с навигацией без can-шины.
Но я повторюсь что это все мне досталось очень выгодно!
Я бы ни за что не купил бы это все за 10т.р
Если есть вопросы задавайте
Всем мир
Getting around MySQL «Can’t reopen table» error
I’m currently busy implementing a filter of sorts for which I need to generate an INNER JOIN clausse for every «tag» to filter on. The problem is that after a whole bunch of SQL, I have a table that contains all the information I need to make my selection, but I need it again for every generated INNER JOIN This basically looks like:
SELECT * FROM search INNER JOIN search f1 ON f1.baseID = search.baseID AND f1.condition = condition1 INNER JOIN search f2 ON f2.baseID = search.baseID AND f2.condition = condition2 . INNER JOIN search fN ON fN.baseID = search.baseID AND fN.condition = conditionN This works but I would much prefer the «search» table to be temporary (it can be several orders of magnitude smaller if it isn’t a normal table) but that gives me a very annoying error: Can’t reopen table Some research leads me to this bug report but the folks over at MySQL don’t seem to care that such a basic feature (using a table more than once) does not work with temporary tables. I’m running into a lot of scalability problems with this issue. Is there any viable workaround that does not require me to manage potentially lots of temporary but very real tables or make me maintain a huge table with all the data in it? Kind regards, Kris [additional] The GROUP_CONCAT answer does not work in my situation because my conditions are multiple columns in specific order, it would make ORs out of what I need to be ANDs. However, It did help me solve an earlier problem so now the table, temp or not, is no longer required. We were just thinking too generic for our problem. The entire application of filters has now been brought back from around a minute to well under a quarter of a second.
asked Dec 5, 2008 at 10:18
40.9k 9 9 gold badges 73 73 silver badges 101 101 bronze badges
I had the same problem using a temporary table twice in the same query using UNION.
Oct 21, 2010 at 17:11
I’m just gonna use a real table then.
Apr 14, 2021 at 1:08
Note that this doesn’t occur on MariaDB.
Aug 28 at 12:36
8 Answers 8
A simple solution is to duplicate the temporary table. Works well if the table is relatively small, which is often the case with temporary tables.
6,869 4 4 gold badges 36 36 silver badges 52 52 bronze badges
answered Jan 28, 2013 at 10:27
1,501 2 2 gold badges 9 9 silver badges 2 2 bronze badges
Should actually be the chosen answer as this answers the problem, without going around.
Aug 25, 2014 at 16:32
any advice on how would you duplicate the table? (I mean a way of copying not repeating the query)
Mar 2, 2016 at 12:40
Even if the temp table is large, mysql’s cache should help you out. As far as copying from one temp table to another, a simple «CREATE TEMPORARY TABLE tmp2 SELECT * FROM tmp1» should do it.
May 10, 2016 at 13:57
If you copy the temptable content, don’t forget to create indexes as well, otwerwise your query may be quite slow.
Apr 29, 2017 at 19:52
@NgSekLong Yes. All the time. It obviously depends on your application for the query but I don’t see «huge» performance issues until > 100,000. In one ETL process, I use this method with a 3.5mil table. That application’s speed isn’t as important though.
Jan 27, 2020 at 19:18
Right, the MySQL docs say: «You cannot refer to a TEMPORARY table more than once in the same query.»
Here’s an alternative query that should find the same rows, although all the conditions of matching rows won’t be in separate columns, they’ll be in a comma-separated list.
SELECT f1.baseID, GROUP_CONCAT(f1.condition) FROM search f1 WHERE f1.condition IN (, , . ) GROUP BY f1.baseID HAVING COUNT(*) = ; answered Dec 7, 2008 at 6:03
Bill Karwin Bill Karwin
544k 86 86 gold badges 676 676 silver badges 833 833 bronze badges
This didn’t actually solve my problem at hand, but it did enable me to simplify the problem that caused it, thus negating the need for the temptable. Thanks!
Dec 8, 2008 at 9:53
I got around this by creating a permanent «temporary» table and suffixing the SPID (sorry, i’m from SQL Server land) to the table name, to make a unique table name. Then creating dynamic SQL statements to create the queries. If anything bad happens, the table will be dropped and recreated.
I’m hoping for a better option. C’mon, MySQL Devs. The ‘bug’/’feature request’ has been open since 2008! Seems like all the ‘bugs’ ‘ve encountered are in the same boat.
select concat('ReviewLatency', CONNECTION_ID()) into @tablename; #Drop "temporary" table if it exists set @dsql=concat('drop table if exists ', @tablename, ';'); PREPARE QUERY1 FROM @dsql; EXECUTE QUERY1; DEALLOCATE PREPARE QUERY1; #Due to MySQL bug not allowing multiple queries in DSQL, we have to break it up. #Also due to MySQL bug, you cannot join a temporary table to itself, #so we create a real table, but append the SPID to it for uniqueness. set @dsql=concat(' create table ', @tablename, ' ( `EventUID` int(11) not null, `EventTimestamp` datetime not null, `HasAudit` bit not null, `GroupName` varchar(255) not null, `UserID` int(11) not null, `EventAuditUID` int(11) null, `ReviewerName` varchar(255) null, index `tmp_', @tablename, '_EventUID` (`EventUID` asc), index `tmp_', @tablename, '_EventAuditUID` (`EventAuditUID` asc), index `tmp_', @tablename, '_EventUID_EventTimestamp` (`EventUID`, `EventTimestamp`) ) ENGINE=MEMORY;'); PREPARE QUERY2 FROM @dsql; EXECUTE QUERY2; DEALLOCATE PREPARE QUERY2; #Insert into the "temporary" table set @dsql=concat(' insert into ', @tablename, ' select e.EventUID, e.EventTimestamp, e.HasAudit, gn.GroupName, epi.UserID, eai.EventUID as `EventAuditUID` , concat(concat(concat(max(concat('' '', ui.UserPropertyValue)), '' (''), ut.UserName), '')'') as `ReviewerName` from EventCore e inner join EventParticipantInformation epi on e.EventUID = epi.EventUID and epi.TypeClass=''FROM'' inner join UserGroupRelation ugr on epi.UserID = ugr.UserID and e.EventTimestamp between ugr.EffectiveStartDate and ugr.EffectiveEndDate inner join GroupNames gn on ugr.GroupID = gn.GroupID left outer join EventAuditInformation eai on e.EventUID = eai.EventUID left outer join UserTable ut on eai.UserID = ut.UserID left outer join UserInformation ui on eai.UserID = ui.UserID and ui.UserProperty=-10 where e.EventTimestamp between @StartDate and @EndDate and e.SenderSID = @FirmID group by e.EventUID;'); PREPARE QUERY3 FROM @dsql; EXECUTE QUERY3; DEALLOCATE PREPARE QUERY3; #Generate the actual query to return results. set @dsql=concat(' select rl1.GroupName as `Group`, coalesce(max(rl1.ReviewerName), '''') as `Reviewer(s)`, count(distinct rl1.EventUID) as `Total Events` , (count(distinct rl1.EventUID) - count(distinct rl1.EventAuditUID)) as `Unreviewed Events` , round(((count(distinct rl1.EventUID) - count(distinct rl1.EventAuditUID)) / count(distinct rl1.EventUID)) * 100, 1) as `% Unreviewed` , date_format(min(rl2.EventTimestamp), ''%W, %b %c %Y %r'') as `Oldest Unreviewed` , count(distinct rl3.EventUID) as `14 Days Unreviewed` from ', @tablename, ' rl1 left outer join ', @tablename, ' rl2 on rl1.EventUID = rl2.EventUID and rl2.EventAuditUID is null left outer join ', @tablename, ' rl3 on rl1.EventUID = rl3.EventUID and rl3.EventAuditUID is null and rl1.EventTimestamp > DATE_SUB(NOW(), INTERVAL 7 DAY) left outer join ', @tablename, ' rl4 on rl1.EventUID = rl4.EventUID and rl4.EventAuditUID is null and rl1.EventTimestamp between DATE_SUB(NOW(), INTERVAL 7 DAY) and DATE_SUB(NOW(), INTERVAL 14 DAY) left outer join ', @tablename, ' rl5 on rl1.EventUID = rl5.EventUID and rl5.EventAuditUID is null and rl1.EventTimestamp < DATE_SUB(NOW(), INTERVAL 14 DAY) group by rl1.GroupName order by ((count(distinct rl1.EventUID) - count(distinct rl1.EventAuditUID)) / count(distinct rl1.EventUID)) * 100 desc ;'); PREPARE QUERY4 FROM @dsql; EXECUTE QUERY4; DEALLOCATE PREPARE QUERY4; #Drop "temporary" table set @dsql = concat('drop table if exists ', @tablename, ';'); PREPARE QUERY5 FROM @dsql; EXECUTE QUERY5; DEALLOCATE PREPARE QUERY5;