I know it's solved, to anyone who cares about how good such a STREXTRACT solution is, you don't have to know details about JSON to understand it and the implications of trying to extract a single bit of information from JSON only. JSON, unlike XML or more generally SGML notations, has no concept of begin and end delimiter. You can take the name of some object property in quotes followed by a colon as a beginning delimiter, that's okayish. But JSON also is correct, if there are spaces between the quoted name and the colon. You don't usually face the problem of any API giving you arbitrary changes of formatting like whitespace changes, so you could argue once the beginning delimiter for STREXTRACT is exactly '"cotacaoVenda":', it stays that and there's no problem using that. I'll not criticize that.
One problem that could arise is that there is no defined end delimiter, though. That doesn't mean the JSON can continue with anything, but it can vary. There are mainly two alternatives: There is a next property/element, separated by a comma from cotacaoVenda, or there is no further and the JSON part ends in a closing curly bracket }. Well, or whatever closing bracket needed to end what cotacaoVenda is part of. That could also be a closing square bracket ]. Again, once an API gives some result structure, that won't change with every single request. But you never know. At least I sense a little understanding from using the comma and the quote " character of the next element as end delimiter, because using only the comma would mean you could interpret a comma within the value of the element you want to extract as the end of the value. In case of textual elements, a comma can clearly be part of a text. In this case, there is no comma to be expected as it's a numerical value and even the usage as thousands separator is not foreseen in JSON. But to make it extremely clear, you are using a hack to detect the end of the cotacaoVenda element that depends on there being a next element.
For the reason of that structural composition of JSON, a more holistic approach is to always parse the whole JSON, even if you're only interested in a single value from it. Otherwise, you can never ensure with certainty you cut off part of the value or you get parts not belonging to the value. In this specific case, imagine the dataHoraCotacao element of the data would be dropped, then that STREXTRACT would result in nothing. And leaving out the end delimiter completely you'd get the number followed by }]} or whatever else comes after the actual value. And the number and type of closing brackets then would also be subject to change.
In very short:
As JSON isn't as easily parsed as XML or other SGML types of notation, you better parse it fully and find the location of the information you want to extract by checking out a sample. This is also subject to change, but there we are in the usual sense of the "subject to change" problem as anything can change its own name or even be dropped or repositioned after a refactoring of code and data structures. This is not the type of "subject to change" and fail, because of a change, against which a wholesome parsing would be stable.
In XML you don't always have the beginning and end delimiters in the form of <tag> and </tag>, too. Because as a variation of that, self-closing tags exist. Those have the structure <tag attribute="value" /> ending in />. That's possible, if they are not a tag type that needs to embed further inner SGML.
Overall, take the recommendation to use the right tool for the job, and that's not STREXTRACT here. While I think nfJSON will make use of STREXTRACT, too, it works quite more complicated, but it works very well and knows the context of the current string position of parsing the JSON. If you think you make it faster and easier to maintain without the dependency of that nfjsonread.prg, that's only half the truth. That's what I want to point out about such hacks.
The other point I don't want to drive that deep is, that you underestimate the complexity JSON can have, if you expect conversion to (VFP) objects always will have a flat structure with all the elements you see in the JSON as elements. Here you have an unusual structure that is an object with an array property that only has 1 element, which is the actual object. You think too simple about JSON, if you think nfJSON fails, because you don't find vfpobj.cotacaoVenda. It's deeper in, that's all.
It is an overcomplicated JSON for what it represents, which illustrates the IT incapabilities of the provider of this JSON. That's just pure opinion, though, and I'm aware this is a governmental API. They will have their reasons - it's all part of more complex data in the first place. But it's not the first time I see something that grotesque coming from a governmental API. It's disconcerting that on the one side, they have their intelligence services up to a point of extreme capabilities of surveillance, but they can't provide the simplest form of data for something that is far less complex. Well, again, that's just my opinion about that. You see, I have too much time on my hand and should care less about things I could care less about.
I reember I once recommended STREXTRACT myself as "scalpel tool in the string functions belt of VFP" in thread184-1817900. There it was in the context of XML which has the tag system of beginning and end delimiters, whereas the role of that in JSON is spread and shared by commas and several bracket types on top of string delimiters, which makes it far more compact than XML. It needs context-sensitive parsing, which isn't possible by the simplicity of STREXTRACT. Not as the only tool, at least.
Chriss
