What is the next prime number? Given an integer 
\begin{equation*}
N~\text{such that}~N\leq 10^{18}, 
\end{equation*}
what is the next prime number after this number? What approach should I use to solve this problem? 
(Problem link: http://www.spoj.com/problems/NAJPLNP/cstart=10 )
 A: See:  Given $N$, what is the next prime $p$ greater than $N$?
Your question seems more programming related than mathematics.  Given your range, you can use a deterministic Miller-Rabin test which will be relatively easy to code, quite fast since you need at most 7 bases, and correct (not probabilistic).  Use a simple trial division pre-test to quickly weed out small factors.
Code examples for M-R can be found at RosettaCode for many languages.  Some examples use deterministic sets, but with the exception of Julia and Perl, they're using inferior sets from 1993.
Deterministic bases good to various limits can be found at Best Known SPRP bases sets.
While not necessary for your example, using either hashed M-R tests or a BPSW test (Miller-Rabin base 2 plus a strong Lucas test) can be somewhat faster albeit more complicated.  There is also faster C code for these tests than shown on RosettaCode (the best bases link shows a couple examples).  These allow next_prime to average only a couple microseconds in the $10^{18}$ range and 5-10x less than that for 32-bit inputs.

In more detail, I would have an is_prime function that took a 64-bit input, answered small cases immediately (e.g. $n < 11$) followed by simple divisibility tests (if $n$ mod 2,3,5,7 is $0$ then return false; again for a few more small primes (taking care with small inputs)), followed by calling the M-R or BPSW function with appropriate arguments.  Your main program can just trivially increment $n$ until this is_prime function returns true.
If you want to get a bit fancier, you could make your main loop use a wheel (skip multiples of 2 or 2/3 or 2/3/5 or 2/3/5/7) but this complicates things for not a lot of gain.  You could also do a partial sieve on a range past $n$, but I haven't found this faster until 120-bit input -- quite a bit larger than your limit.  Neither of these seem at all necessary for your example.
