Java call to getObjectCount (synchronous) on table generates exception

App ID: AF2A35B6-5300-675D-FFB8-EC3622523000

Table Name: UserStuck

Hello BL team!

In my Java Business-Logic, I call getObjectCount() on a table and it generates this exception…but I’m not sure what it means or why. I’m calling synchronous getObjectCount with no parameters. I get an exception whether the table is empty or has data.

Exception:
Tue Oct 09 2018 15:51:00 GMT-0700 (Pacific Daylight Time) | Coderunner | ERROR | Business logic execution has been stopped, due to error: Code: 0 Class: com.backendless.exceptions.BackendlessException Message: java.lang.RuntimeException: org.jooq.exception.DataAccessException: SQL [select distinct count(udt.UserStuck.objectId) from udt.UserStuck left outer join 59D741BB-6CFE-7101-FF2A-B2566928F000.acl on (59D741BB-6CFE-7101-FF2A-B2566928F000.acl.objectId = udt.UserStuck.objectId and 59D741BB-6CFE-7101-FF2A-B2566928F000.acl.granted = ? and 59D741BB-6CFE-7101-FF2A-B2566928F000.acl.operationId = ? and 59D741BB-6CFE-7101-FF2A-B2566928F000.acl.userId = ?) left outer join 59D741BB-6CFE-7101-FF2A-B2566928F000.role_acl on (59D741BB-6CFE-7101-FF2A-B2566928F000.role_acl.objectId = udt.UserStuck.objectId and 59D741BB-6CFE-7101-FF2A-B2566928F000.role_acl.operationId = ? and (59D741BB-6CFE-7101-FF2A-B2566928F000.role_acl.role & ?) = ?) where case when (59D741BB-6CFE-7101-FF2A-B2566928F000.acl.objectId is null and 59D741BB-6CFE-7101-FF2A-B2566928F000.role_acl.objectId is null) then case when udt.UserStuck.ownerId is null then ? else case when udt.UserStuck.ownerId = ? then ? else ? end end else ? end]; Table ‘AF2A35B6-5300-675D-FFB8-EC3622523000.59D741BB-6CFE-7101-FF2A-B2566928F000.acl’ doesn’t exist

Code snippet:
IDataStore table = Backendless.Data.of(UserStuck.class);
if (table.getObjectCount() == 0) return 0; // This line generates the above exception. But why?

Oddly, this same code works fine in my “Dev” app…but in my “Prod” app, it generates this exception. Maybe something is broken internally with this table? Again, the name of the table is “UserStuck”.

Thanks for any help.
-Brian
brian@trpz.com

Hi Brian,
We’ve found an internal issue related to the default database encoding, which prevented you from creating new tables properly. This has been fixed for your app’s database and I’ve successfully recreated the UserStuck table.
We’re also going to investigate this further and come up with a general fix for all older apps.
Thank you for reporting!

Thank you very much! :slight_smile:
-Brian

Could this issue have affected our app’s performance (with respect to reading/writing tables) ?

No, this one doesn’t affect performance. We’re already working on the performance issues separately.