Rajesh,

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

Вариант, предложенный по первой ссылке skyANA описывает реализацию именно кольцевого буфера (а не кольцевой очереди), в которой проектировщик закладывается на встроенный в SQL Server тип данных rowversion, он же timestamp в более ранних версиях.

Если аналогичный тип есть в Compact Edition (скорее есть, чем нет), то можно взять предложенную реализацию без доп. подкруток.
Если нет, то нужно изобрести замену для rowversion.
Вроде счетчика с переустановкой стартового значения. Здесь потребуются доп усилия по поддержке переустановки счетчика на 1е значение.
Т.к., вероятнее всего, задача ваша одно-пользовательская и одно-поточная, поддержка "окон вставки" для нескольких одновременно идущих сеансов не потребуется.
Просто прочтите текст по первой ссылке. С высокой вероятностью это почти готовое для вас решение ( при наличии в compact edition подходящего типа), не требующее большого допиливания по месту.
М.б., какое-то доп внимание потребуют "СтолбецА, СтолбецБ" в случае, если они текстовые (Это зависит от деталей того, как движок реализует работу с текстовыми полями).

Rajesh...86400 записей....Потом по таймеру каждую секунду делать UPDATE, потом когда номер строки дойдет до 86400, делать номер строки равным 1...
По производительности это нормальное решение?

При таком объеме данных любое произвольно взятое - даже самое неудачное решение - "по производительности" будет почти наверно "нормальным".
Черти как всегда в деталях.
Я не знаю, почему и зачем Вам авторПотом по таймеру каждую секунду делать UPDATE
Но, может оказаться так, что по каким-то причинам, фактический "апдейт" окажется не через секунду, а через 2.5

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

Видно вот что: этот вопрос - в решении, предлагаемом по ссылке skyANA - полностью "замазан".
т.е. - пропусков там не будет, в плане оставшихся не перезаписанными, строк.
Если Вы ориентируетесь в SQL, то перезапись варианта того запроса для случая 86400 нумерованных строк очевидна.
И, в среднем, Вы "почти всегда" попадете в "свою" секунду.

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

авторЭто конечно удобно когда удаляется первая, а последняя записывается в конце, но мне сказали что на самом деле строки не удялются а где-то остаются, это правда?

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

б) Приемлемо или нет конкретное решение, в плане организации таблиц и запросов, работающих с ними невозможно принять на основе понимания только свойств таблиц и знания особенностей той или иной системы хранения данных.

Это понимание должно быть положено на детальное понимание существа вашей задачи безотносительно к таблицам.
А об этом Вы ни одного содержательного слова не сказали.

PS
Дерзайте.
Рано или поздно у Вас все получится.
Даже если это будет стоить самооценки, карьеры и финансового благополучия, может быть стоило во все это ввязаться.
"Хочу" всегда важнее "мог"у. Без первого не бывает второго.
Это уважаемо, если стартующий готов сгинуть навеки под своей задачей.