If you need a "symbolic solution" then I understand. Put this

Reduce[dx - djep (-(1/4) Sqrt[3] dq (1 - Cos[a0 + da p]) Cos[dq p + q0] + 1/2 da Cos[a0 + da p] Cos[dq p + q0] - 
      1/4 Sqrt[3] da Sin[a0 + da p] Sin[dq p + q0] - 1/2 dq Sin[a0 + da p] Sin[dq p + q0]) == 0, p]

on the fastest machine with the most memory you can buy and wait to see if it ever finishes.

Adding constraints on some or all values will sometimes speed the process up and sometimes greatly slow the process down. If you know some information about the system that would allow you to significantly simplify the problem then that might help a great deal, but trying to decide what would or would not be helpful can be very challenging.

The reason you are getting different answers is probably because you are using slightly different code than I did. That is why I always show exactly what all my input and output are from a single fresh run of any problem.

As an example, there was a question posed in the last few days about why there was a completely different result when all that was done was to change the name of a variable. Mathematica isn't like the old days with FORTRAN. There are literally thousands and often tens of thousands of lines of code and half a dozen completely different algorithms hiding behind a name as simple as Reduce and there is often nearly zero connection between what tiny change you make and how it will interpret the question. But you almost certainly could not justify writing your own code in FORTRAN to answer your question.

It is only a guess on my part, but I expect that if you do get the complete symbolic solution to this problem that the result will be far too complex to be of any use to you. I certainly may be wrong and there may be a simple two-line answer to your problem, but I doubt it.

Without specifying the values of the variables, with or without constraints on the variable ranges, I believe Reduce is probably your only viable option.

Throw the problem at the fast machine, wait a day and see if you get an answer. If not then give it a month and see if you get lucky. If you don't get it in a month then I would guess it would be very unlikely to be worth waiting a year. Unfortunately I don't believe there is any way to know whether it is making significant progress while you are waiting.

I hope it works

New users see the word "Solve" and assume this will find the answer to any problem. Human understanding of the definitions of words would make you think that. Solve is perhaps a poor choice of a name for that function. If it had been named "ThisDoesAGoodJobWhenYouAreAskingItToSolvePolynomialProblemsButProbablyNotTrigOrExponentialOrMoreComplicated" then there might be less confusion and waiting for answers that will never come. Or, behind the scenes Solve could peek at the problem, see it isn't a polynomial problem and likely never to "solve" and hand the problem off to other functions better able to find an answer. Reduce can sometimes find an answer that Solve cannot, but Reduce has other expectations and issues.

Is this closer to what your problem really is, with all the variables except p having exact known values with no decimal points anywhere?

In[1]:= a0 = -135*(Pi/180);
a1 = 135*(Pi/180);
da = a1 - a0;
djep = 450;
o0 = 0*(Pi/180);
o1 = 90*(Pi/180);
do = o1 - o0;
q0 = -360*(Pi/180);
q1 = 360*(Pi/180);
dq = q1 - q0;
r = 200;
x0 = 0;
x1 = 1000;
dx = x1 - x0;

In[15]:= Plot[dx - djep (-(1/4) Sqrt[3] dq (1 - Cos[a0 + da p]) Cos[dq p + q0] + 
     1/2 da Cos[a0 + da p] Cos[dq p + q0] - 1/4 Sqrt[3] da Sin[a0 + da p] Sin[dq p + q0] - 
     1/2 dq Sin[a0 + da p] Sin[dq p + q0]), {p, 0, 2 Pi}]

Out[15]= ...PlotSnipped...

In[17]:=N[Reduce[dx - djep (-(1/4) Sqrt[3] dq (1 - Cos[a0 + da p]) Cos[dq p + q0] + 
         1/2 da Cos[a0 + da p] Cos[dq p + q0] - 1/4 Sqrt[3] da Sin[a0 + da p] Sin[dq p + q0] - 
         1/2 dq Sin[a0 + da p] Sin[dq p + q0]) == 0 && 0 <= p < 2 Pi, p]]

Out[17]= p == 2.20997 || p == 6.20997 || p == 2.38766 || 
 p == 2.61234 || p == 2.79003 || p == 3.02473 || p == 3.11558 || 
 p == 3.30052 || p == 3.44698 || p == 3.67619 || p == 3.85618 || 
 p == 0.0820155 || p == 4.08202 || p == 0.251802 || p == 4.2518 || 
 p == 0.486734 || p == 4.48673 || p == 0.513266 || p == 4.51327 || 
 p == 0.748198 || p == 4.7482 || p == 0.917984 || p == 4.91798 || 
 p == 1.14382 || p == 5.14382 || p == 1.32381 || p == 5.32381 || 
 p == 1.55302 || p == 5.55302 || p == 1.69948 || p == 5.69948 || 
 p == 1.88442 || p == 5.88442 || p == 1.97527 || p == 5.97527

If I've misunderstood then perhaps you could explain what is known, what is unknown, and what the problem really is.

After you have evaluated the above code, but before doing anything else, you can compare the result from

NSolve[dx - djep (-(1/4) Sqrt[3] dq (1 - Cos[a0 + da p]) Cos[dq p + q0] + 
       1/2 da Cos[a0 + da p] Cos[dq p + q0] - 1/4 Sqrt[3] da Sin[a0 + da p] Sin[dq p + q0] - 
       1/2 dq Sin[a0 + da p] Sin[dq p + q0]) == 0 && 0 <= p < 2 Pi, p]

and the result from

Solve[dx - djep (-(1/4) Sqrt[3] dq (1 - Cos[a0 + da p]) Cos[dq p + q0] + 
       1/2 da Cos[a0 + da p] Cos[dq p + q0] - 1/4 Sqrt[3] da Sin[a0 + da p] Sin[dq p + q0] - 
       1/2 dq Sin[a0 + da p] Sin[dq p + q0]) == 0 && 0 <= p < 2 Pi, p]

where NSolve is sort of like an old calculator that just deals with digits and approximate answers, while Solve, and Reduce, want to give you trig functions and inverse trig functions and polynomials and... When I did N[Reduce[yourproblem]] above Reduce created a huge solution and then N turned into decimal approximations and made it dozens of times smaller and perhaps easier to understand and use.

To be honest, I'm surprised Solve was able to find an answer, I never expected that to work. I had tried Solve and Reduce, without telling it the values of all your other variables and waited long enough that I guessed it would never finish. Then I tried Reduce after telling it all the variable values and was happy to see an answer. As an afterthought I tried NSolve and Solve and got answers, but that only happened because I had already told it the values of all your other variables. That just shows that even if you think you know a lot about how Mathematica works, it can still do surprising things you didn't expect.

One tip, be really careful about using decimal points anywhere in a problem in Mathematica. If you insert a decimal point almost any place in a calculation the whole problem can turn into an approximate result. You may or may not want that. Experiment and see what happens.