1304 error - possible issue on codeless side


I have a service which was create while ago. It suddenly stopped working and the error seems to be a bit odd. The service is just using “Load Table Objects”, “Load Object Relations” and “Get Object Count”. Could you please advise what is this error code and whether something hasn’t been changed in the implementation on the backendless codeless side?

Below error:

400 - Unable to create relation. Unknown column name - ‘find’. Make sure the column is created first with the ‘column creation API’ or in Backendless Console. (1304)

Hi Jakub,

The error implies that a relation is being created somewhere. How can we reproduce the error? Can we try invoking your service? If so, need the following info:

  • app id
  • service name
  • method name
  • argument values


Hello Mark, sure please find required details:

  • app id: F7217991-455B-46B8-886F-505F8B71BEBA
  • method name: GetRestaurantInfoPage
  • argument values: restaurantId: C11E70C1-2D52-47CB-81FD-0D0DA44B4C44

Please let me know if I can help somehow.
Best Regards,

Hello @mark-piller - quick update on the issue. After a detailed investigation from our side, it seems that the issue occurs when Load Table Objects passes ID of the object in the url as serviceName/XXXXXX, where XXXXX is the objectID. It looks like some update has been done on the backendless side that has broken this.
Please note that the same call works fine from the REST console so it seems that the root cause is on the codeless side.
Below fragment of the code that has been built based on the codeless blocks.
(await Backendless.Data.of((String(‘Users/’) + String(this.request.context.userId))).find(Backendless.DataQueryBuilder.create().setProperties([’*’]).setRelated

Hope that helps to quickly investigate the issue and roll back the changes that caused it.

Thank you in advance,

Hello @mark-piller have you had a chance to look at above? It is kind of a showstopper as it impacted most of the APIs.


Hello @Jakub_Patoleta ,

I have tried to invoke GetRestaurantInfoPage method with provided restaurantId and got a successful response at this time.

Did you do something with logic? Is it still results in error for you?


@stanislaw.grin can you please try once again?

@Jakub_Patoleta now I catched it. Need time to investigate this.
Did you change something?

I have created an internal ticket in order to investigate and resolve this issue (you may reference it by it’s ID BKNDLSS-24898).

We will keep you updated about any progress here.


Hello @Jakub_Patoleta

Yes, you are right, this is the issue. Recently we changed the find method in the JS-SDK (which is used in the Codeless logic), now it add /find at the of the URL and uses POST method.

As I understand you compose the table name {tableName}/{objectId} in order to load a single object along with its relations, am I right?
I just created a new internal ticket to add a new block FindById with all the related parameters, such as: relations, properties, etc. This should solve your problem.

While it is not done, you can add where clause objectId = '{YOUR_OBJECT_ID}' and then get the first element

Regards, Vlad

Hello @vladimir-upirov is there a chance to keep the backward capability? It will take bigger effort to change each current service.
I was thinking about that workaround but again, this adds an effort to change all services and test them again. Additionally, can you please confirm whether this has any impact on the performance while using where instead of the previous “/{objectId}” approach?

I’m sorry but the backward compatibility is not broken, the find table objects block still works as it did before the fix. In your case, this is more like a hack, instead of a table name you attach it with an objectId.
According to the performance, I believe it works much faster when you request an object by its id directly, however, we are going to add a new codeless block for this asap.