Db.json Not Found

[Azucena Mcquay]

Fromdocumentation that I read, I understand that the layer in json (or html) format will be in the input box. I can then copy, edit and paste back to modify it. But my input box is blank. Just checking whether it is supposed to be blank or not.

Have any of you found a solution to the original question? We are having the same issue while attempting to Update Definition on a local ArcGIS Server 10.4.1 rest service. This problem does not occur with an ESRI-hosted feature service, just with local, AGS-hosted rest service (feature services).

Scenario: Published Oracle enterprise db (sde 10.1) feature classes/table to AGS 10.4.1 using ArcGIS Desktop 10.4.1. Fields that are set to required with a domain assigned are the problem. The JSON for each rest service shows that the templates default values for those fields are set to 0 or " " - instead of null. No way to fix this otherwise.

There is actually a logged enhancement in our system to address this. It is expected that the Update Definition operation for Portal would be different than that seen in ArcGIS Online, but there is still a means of using this operation without having to construct the entire JSON manually.

Has anybody had any success getting this to work in a Portal 10.6 environment? I've got a simple hosted feature service layer for which I want to add an extra value into the domain on one of the fields. I've used the second method above to get the json for the part I want to update and have posted via the update definition page for the layer. I get a message back saying success is true but the change doesn't seem to have come through to the layer itself.

When I am working on an Angular application, there are times I want to run the app without the backing API running as well. I want fast feedback on the changes I make to components and want my site to work by itself.

One way I have done this is to use a fake Angular service that acts like the real one. I use the fake service when developing locally. That works to achieve my goal, but it tends to be painful to maintain, or it can hide problems in my actual service.

Recently, I have found another way to keep my Angular application using its real services and still use mock data instead of calling my API. I have been using a tool called JSON Server to accomplish my goal of running my Angular application without my backend API running.

JSON Server gives me the power to set up specific, unchanging mock API responses. This allows me to build and test my Angular application in a repeatable, expected way. I can run my Angular app without modification, testing all its functionality exactly how it will run against the real REST API, but done in isolation from that REST API.

I have found that using JSON Server with Angular applications has simplified the development process, facilitated testing, and allowed for efficient frontend-backend interaction without the need for complex mocking. This tool is worth exploring for software engineers looking to enhance their development workflow.

I encountered the same error and found out that I made the mistake with my powershell script that collected the json data. I addded multiple results to the same file, which works quite ok with CSV files but not with Json

My solution was to select the Binary column, Transform -> Trim Text then set the type back to Binary. Following this I could click on the Binary and see the JSON without experiencing the 'We found extra characters at the end of JSON input.' error.

What kind of setting did you use on this?

If I use the default suggested setting and the "Colon" as delimiter, the output seems to be very strange, and looks much the same as in the screen shot above.

it will be possible to do a extended amount of transformation on the data, but that seems very uncecessary and there should be a way to actually get the data into PowerBI withouth any work.

Have you managed to make it work and that the data looks as expected?

Regards

Oddmar

I faced the same error message in Excel - Power Query editor.

A reason for that issue was wrongly selected VPN. After switching to a correct one that message is gone and a query is executed successfylly.

Hope it may help to someone )

Very weird ......the same i am facing issue but this is all of a sudden . I am trying to call api from table in power bi and it was working fine like 2 weeks back and now all of sudden getting this issue of "extra characters found at the end of JSON" . Is it like any rules of JSON parser changed or anything ... Unfortunately couldnt find a solution for this ... ... Can anyone please help me with this if you have solved this issue ..... My query goes like

(Name1 as text,Name2 as text) =>

let

Source = Json.Document(Web.Contents("URL",[Headers=[Accept="Basic base64- PAT ]])),

- If it works -> now create another query and source all your JSON files. Use the "add column" -> "invoke custom function" and fill in the name of your function and click the file path as the function's source.

I'm having same issue when loading JSON from folder. Doing the first time works ok, but when updating, it appears "We found extra characters at the end of JSON INPUT.

Please correct this old error from 2016

I'm stuck with the same problem. I'm trying to build a Power BI custom connector, and I'm not even sure that the request by Web.Contents is executed, since I've tried inserting the json as a string in the Power Query and that works, but if I place the same string as a json-file on App Service or as Blob it fails. I'm stranded with with an option on how to trace/debug what really happens.

The SQL/JSON function JSON_TABLE creates a relational view of JSON data. It maps the result of a JSON data evaluation into relational rows and columns. You can query the result returned by the function as a virtual relational table using SQL. The main purpose of JSON_TABLE is to create a row of relational data for each object inside a JSON array and output JSON values from within that object as individual SQL column values.

You must specify JSON_TABLE only in the FROM clause of a SELECT statement. The function first applies a path expression, called a SQL/JSON row path expression, to the supplied JSON data. The JSON value that matches the row path expression is called a row source in that it generates a row of relational data. The COLUMNS clause evaluates the row source, finds specific JSON values within the row source, and returns those JSON values as SQL values in individual columns of a row of relational data.

JSON_exists_column - Evaluates JSON data in the same manner as the JSON_EXISTS condition, that is, determines if a specified JSON value exists, and returns either a VARCHAR2 column of values 'true' or 'false', or a NUMBER column of values 1 or 0.

JSON_query_column - Evaluates JSON data in the same manner as the JSON_QUERY function, that is, finds one or more specified JSON values, and returns a column of character strings that contain those JSON values.

JSON_nested_path - Allows you to flatten JSON values in a nested JSON object or JSON array into individual columns in a single row along with JSON values from the parent object or array. You can use this clause recursively to project data from multiple layers of nested objects or arrays into a single row.

The column definition clauses allow you to specify a name for each column of data that they return. You can reference these column names elsewhere in the SELECT statement, such as in the SELECT list and the WHERE clause.

Appendix C in Oracle Database Globalization Support Guide for the collation derivation rules, which define the collation assigned to each character data type column in the table generated by JSON_TABLE

Use this clause to specify the JSON data to be evaluated. For expr, specify an expression that evaluates to a text literal. If expr is a column, then the column must be of data type VARCHAR2, CLOB, or BLOB. If expr is null, then the function returns null.

If expr is not a text literal of well-formed JSON data using strict or lax syntax, then the function returns null by default. You can use the JSON_table_on_error_clause to override this default behavior. Refer to JSON_table_on_error_clause.

Use the PATH clause to delineate a portion of the row that you want to use as the column content. The absence of the PATH clause does not change the behavior with a path of '$.', where is the column name. The name of the object field that is targeted is taken implicitly as the column name. See Oracle Database JSON Developer's Guide for the full semantics of PATH.

If the input is not well-formed JSON text, no more rows will be returned as soon as the error is detected. Note that since JSON_TABLE supports streaming evaluation, rows may be returned prior to encountering the portion of the input with the error.

Use this clause to specify the value returned by this function if no match is found when the JSON data is evaluated using the SQL/JSON path expression. This clause allows you to specify a different outcome for this type of error than the outcome specified with the JSON_table_on_error_clause.

This clause evaluates JSON data in the same manner as the JSON_EXISTS condition, that is, it determines if a specified JSON value exists. It returns either a VARCHAR2 column of values 'true' or 'false', or a NUMBER column of values 1 or 0.

You can use the JSON_value_return_type clause to control the data type of the returned column. If you omit this clause, then the data type is VARCHAR2(4000). Use column_name to specify the name of the returned column. The rest of the clauses of JSON_exists_column have the same semantics here as they have for the JSON_EXISTS condition. For full information on these clauses, refer to "JSON_EXISTS Condition". Also see "Using JSON_exists_column: Examples" for an example.

This clause evaluates JSON data in the same manner as the JSON_QUERY function, that is, it finds one or more specified JSON values, and returns a column of character strings that contain those JSON values.

3a8082e126