# Query parsing errors when using SERVICE block **URL:** \ **Category:** Bug\ **Created:** [May 10, 2019, 9:23am UTC](https://community.stardog.com/t/query-parsing-errors-when-using-service-block/1654 "2019-05-10T09:23:36Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![onto\_rory](https://avatars.discourse-cdn.com/v4/letter/o/c37758/32.png) [@onto\_rory](https://community.stardog.com/u/onto_rory)\ **Post date:** [May 10, 2019, 9:23am UTC](https://community.stardog.com/t/query-parsing-errors-when-using-service-block/1654/1 "2019-05-10T09:23:36Z")
Hi I've created 2 databases (with query.all.graphs set to **true** ) in 6.1.2. All queries were via Studio In _testing_ DB I created the data as follows ``` prefix alu: prefix : insert data { :thing1 alu:cardId "1" . :thing2 alu:cardId "2" . :thing3 alu:cardId "3" . :thing4 alu:cardId "4" . } ``` And in the _other_ DB I created the data as follows ``` prefix alu: prefix : insert data { :thing1 alu:type "AACU-A" . :thing2 alu:type "AACU-B" . :thing3 alu:type "AACU-C" . :thing4 alu:type "AACU-C" . } ``` Then I ran the following query against the _testing_ DB ``` prefix alu: select * where { service { select ?c where { ?c alu:type "AACU-C" } } # ?c ?p ?o . ?c alu:cardId ?id . } ``` I'm pretty sure it's valid SPARQL (online validators agree) but it gives the following error ``` Caused by: com.complexible.stardog.plan.eval.operator.OperatorException: Encountered " "where" "WHERE "" at line 11, column 1. Was expecting one of: "(" ... "!" ... "^" ... "a" ... ... ... ... ... ... at com.complexible.stardog.KernelDatabaseService$KernelDatabaseServiceQuery.evaluateBatch(KernelDatabaseService.java:130) ~[stardog-6.1.2.jar:?] at com.complexible.stardog.plan.eval.service.BatchingJoinArgServiceQuery$BatchingJoinArgIterator.nextIterator(BatchingJoinArgServiceQuery.java:128) ~[stardog-6.1.2.jar:?] at com.complexible.stardog.plan.eval.service.BatchingJoinArgServiceQuery$BatchingJoinArgIterator.computeNext(BatchingJoinArgServiceQuery.java:135) ~[stardog-6.1.2.jar:?] at com.complexible.stardog.plan.eval.service.BatchingJoinArgServiceQuery$BatchingJoinArgIterator.computeNext(BatchingJoinArgServiceQuery.java:93) ~[stardog-6.1.2.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141) ~[guava-26.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136) ~[guava-26.0-jre.jar:?] at com.complexible.stardog.plan.eval.operator.impl.ServiceOperatorImpl.computeNext(ServiceOperatorImpl.java:89) ~[stardog-6.1.2.jar:?] at com.complexible.stardog.plan.eval.operator.impl.ServiceOperatorImpl.computeNext(ServiceOperatorImpl.java:34) ~[stardog-6.1.2.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-6.1.2.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-6.1.2.jar:?] at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:82) ~[stardog-6.1.2.jar:?] at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:29) ~[stardog-6.1.2.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-6.1.2.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-6.1.2.jar:?] at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:112) ~[stardog-6.1.2.jar:?] at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:25) ~[stardog-6.1.2.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-6.1.2.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-6.1.2.jar:?] at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:116) ~[stardog-6.1.2.jar:?] at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:39) ~[stardog-6.1.2.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141) ~[guava-26.0-jre.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136) ~[guava-26.0-jre.jar:?] at com.complexible.common.rdf.query.IteratorAsTupleQueryResult.hasNext(IteratorAsTupleQueryResult.java:78) ~[stardog-utils-rdf-6.1.2.jar:?] ... 15 more ``` Switching to the _?c ?p ?o_ pattern instead of the _?c alu:cardId ?id_ gave the same error with these 2 test DBs. Weirdly, in the 'real' DBs I was using for testing and originally saw the issue, it then worked OK and returned the expected results! (they had identical data - 489m quads). I was initially using the _?c ?p ?o_ pattern to see if it worked OK, and after it did, I wanted to then filter down the data to named properties ---
**Author:** ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)\ **Post date:** [May 10, 2019, 10:21am UTC](https://community.stardog.com/t/query-parsing-errors-when-using-service-block/1654/2 "2019-05-10T10:21:25Z")
Hi Rory, Thanks for the report. We'll take a deeper look today at 6.1.2 but I tried with 6.2 and it seemed to work, i.e. I got ```auto +---------------------------------------------+-------+ | c | id | +---------------------------------------------+-------+ | http://some.testing/voc/olt/alu/inst#thing3 | "3" | | http://some.testing/voc/olt/alu/inst#thing4 | "4" | +---------------------------------------------+-------+ ``` I had to tweak prefix declarations a little since `alu:` resolves to `` in testing but to `` in other. It's possible that the server chooses different evaluation strategies based on whether the pattern which is joined with the SERVICE is selective or not. That could explain the bug appearing after changing `?s ?p ?o` to `?c alu:cardId ?id`. Cheers, Pavel PS. It seems like you don't need the projection in the SERVICE for this query, i.e. could be simplified to ```auto prefix alu: select * where { service { ?c alu:type "AACU-C" } ?c alu:cardId ?id . } ``` but it might make a difference for a more complex SERVICE query, esp. in a combination with DISTINCT. ---
**Author:** ![onto\_rory](https://avatars.discourse-cdn.com/v4/letter/o/c37758/32.png) [@onto\_rory](https://community.stardog.com/u/onto_rory)\ **Post date:** [May 10, 2019, 10:40am UTC](https://community.stardog.com/t/query-parsing-errors-when-using-service-block/1654/3 "2019-05-10T10:40:31Z")
Re the _[some.testing.com](http://some.testing.com)_ - sorry, that's my bad. I used difference namespaces in actual testing and changed them to hide some details in the report and left a rogue .com floating around I'll try to have a go on a new download of 6.2 on the bigger datasets