SQL Server Query not returning results

By default, the HttpSessionState.Mode Property is set to “Off”, and to be sure I also set this in web.config for the application. I commented it out to see what would happen and I get a different error message from the records.aspx page when I run it:
In Firefox:
“SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data”
In Chrome:
“A server error occured, to see the error enable the DEBUG flag.”

Thank you

Actually the default is that it stores the sessions in memory.

Session Modes

ASP.NET session state supports several storage options for session variables. Each option is identified as a session-state Mode type. The default behavior is to store session variables in the memory space of the ASP.NET worker process. However, you can also specify that session state should be stored in a separate process, in a SQL Server database, or in a custom data source. If you do not want session state enabled for your application, you can set the session mode to Off

What is your recommendation?

The null reference exception was caused because you didn’t had session state enabled. I will see if I can better check that and make server connect also work without that being enabled.

For now just enable it, for the last error it seems that server connect is running but there is an error with one of the actions it is running. Turn on debug in server connect to see the actual error message.

Not sure where “server connect” is.
I turned on a debug switch on my query properties, is that it?

No, it;'s not that one. the query debug should be off.
It’s this one:

I found it, it is not where you indicated but I found it under Workflow panel–>Server Connect Settings–>General.

Now I can see the error message and I’ll paste the inner stack trace after the screen shot:

Inner Stack Trace:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction)\r\n at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction)\r\n
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)\r\n
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)\r\n
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()\r\n
at System.Data.SqlClient.SqlDataReader.get_MetaData()\r\n
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption, Boolean shouldCacheForAlwaysEncrypted)\r\n
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)\r\n
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)\r\n
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)\r\n
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)\r\n
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)\r\n
at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()\r\n
at DMXzone.ServerConnect.Database.Connector.Execute(SqlBuilder sql) in C:\Development\Server Connect\ASPNET_Source\DMXzone Database Connector\Database\Connector.cs:line 175\r\n
at DMXzone.ServerConnect.Module.DbConnectorModule.Select(JObject options) in C:\Development\Server Connect\ASPNET_Source\DMXzone Database Connector\Module\DbConnectorModule.cs:line 104"

The error references this table, but the name is correct:
2022-09-29_08h53_33

The Wappler query window:

How does the json of the action look like? You can use the open in code editor in Wappler to see it, they are located in the App_Data/ServerConnect/Api folder.

I think it tries to do SELECT PF_FunctionNodeID FROM "dbo.Invoices.FunctionCodes" instead of SELECT PF_FunctionNodeID FROM dbo.Invoices.FunctionCodes. You can also test it by using a custom query and build the query yourself.

It is very bad idea to use dots in table names. You really should use underscore instead.

See:

Thanks Patrick.
Here’s the records.json file:

Hi,
When I click on “Database Custom Query”, the dialog box goes away but nothing else happens.
Am I doing the correct sequence? (see below)

Thank you

Thanks for the link.
I have never heard of this before. Since MS SQL Server prefixes table names with a schema and a period, I figure it’s standard practice. Even their best practices sample database, “AdventureWorks”, uses dot notation in the table names. I’ve never encountered any situation where it has caused an issue so I’ve always followed it.
Is using schema with dot notation not supported in Wappler?

What you see here in Adventure works is the user name prefixes - not table names.
So the owner user name or schema name.

Usually the schema is dbo - but can be also a different users to control the access to those tables.

How did you created those tables? As those schema names has to be escaped correctly to make them work.

Hi,
I create the tables within SSMS and use dot notation to group tables into logical categories. They aren’t schemas, per se. Everything is automatically prefixed with dbo since I am the one creating them. SSMS does this, not me. It’s not something I override, nor is there any reason to.
The AdventureWorks db uses actual schemas (not users) as shown below. Categorizing the tables is the same idea.
Again, this has never been an issue. Does Wappler not support schemas using dot notation (e.g. ‘dbo.’)?


If they are defined as schema’s they will be recognized all fine.

If not as schema’s there will be a ambiguity between with our without the dbo prefix which will give you problems.

Hi, just to be clear…the ‘dbo.’ (‘dbo’ + ‘.’ period) will not work with Wappler, correct?