When i tried to read extended event file for azure database its giving an following error :
I am able to download .xel file from blob storage and view it through SSMS.
select * from sys.fn_xe_file_target_read_file ( 'http location of .xel file', null, null, null ) but its not user friendly.
Is there is any another way we can view extended event .xel file?
There is only one way that I can think of to make the interface more user-friendly and it is to create your own. I do not know if you have the time to invest into the task, but in a similar situation I used this library to query and parse xEvents with linq (it is the same library that Microsoft uses for the SSMS extended events viewer in SQL Server 2016).
Related
Can I write an UPDATE statement for Azure Cosmos DB? The SQL API supports queries, but what about updates?
In particular, I am looking to update documents without having to retrieve the whole document. I have the ID for the document and I know the exact path I want to update within the document. For example, say that my document is
{
"id": "9e576f8b-146f-4e7f-a68f-14ef816e0e50",
"name": "Fido",
"weight": 35,
"breed": "pomeranian",
"diet": {
"scoops": 3,
"timesPerDay": 2
}
}
and I want to update diet.timesPerDay to 1 where the ID is "9e576f8b-146f-4e7f-a68f-14ef816e0e50". Can I do that using the Azure SQL API without completely replacing the document?
The Cosmos DB SQL language only supports the Select statement.
Partially updating a document isn't supported via the sql language or the SQL API.
People have made it clear that that's a feature they want so there is a highly upvoted request for it that can be found here: https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6693091-be-able-to-do-partial-updates-on-document
Microsoft has already started to work on that so the only thing you can do is wait.
To elaborate more on this, Updating partially a document in CosmosDb on the server isn’t possible, instead you can do whatever you need to do in the memory.In order to literally UPDATE the document, you will have to to retrieve the entire document from the CosmosDb, update the property/properties that you need to update and then call the ‘Replace’ method in the CosmosDb SDK to replace the document in question. Alternatively you can also use ‘Upsert’ which checks if the document already exists and performs an ‘Insert’ if true or ‘Replace’ if false.
NOTE : Make sure you have the latest version of the document before you commit an update!
UPDATE :
CosmosDB support for Partial Update is GAed. You can read more from here
You can use Patch API for partial updates.
Refer: https://learn.microsoft.com/en-us/azure/cosmos-db/partial-document-update
As of 25.05.2021 this feature is available in private preview and will hopefully be in GA soon.
https://azure.microsoft.com/en-us/updates/partial-document-update-for-azure-cosmos-db-in-private-preview/
Use Robo3T to update/delete multiple records with mongo db commands. Make sure your query includes the partition key.
db.getCollection('ListOfValues').updateMany({type:'PROPOSAL', key:"CITI"},{$set: {"key":"CITIBANK"}})
db.getCollection('ListOfValues').deleteMany({type:'PROPOSAL', key:"CITI"})
I'm using DocumentDB Data Migration Tool to migrate a documentDB db to a newly created documentDB db. The connectionStrings verify say it is ok.
It doesn't work (no data transferred (=0) but not failure written in the log file (Failed = 0).
Here is what is done :
I've tried many things such as :
migrate / transfer a collection to a json file
migrate to partitionned / non partitionned documentdb db
for the target indexing policy I've taken the source indexing policy (json got from azure, documentdb db collection settings).
...
Actually nothing's working, but I have no error logs, maybe a problem of documentdb version ?
Thanx in advance for your help.
After debugging the solution from the tool's repo I figure the tools fail silently if you mistyped the database's name like I did.
DocumentDBClient just returns an empty async enumerator.
var database = await TryGetDatabase(databaseName, cancellation);
if (database == null)
return EmptyAsyncEnumerator<IReadOnlyDictionary<string, object>>.Instance;
I can import from an Azure Cosmos DB DocumentDB API collection using DocumentDB Data Migration tool.
Besides, based on my test, if the name of the collection that we specify for Source DocumentDB is not existing, no data will be transferred and no error logs is written.
Import result
Please make sure the source collection that you specified is existing. And if possible, you can try to create a new collection and import data from this new collection, and check if data can be transferred.
I've faced same problem and after some investigation found that internal document structure was changed. Therefor after migration with with tool documents are present but couldn't be found with data explorer (but with query explorer using select * they are visible)
I've migrated collection through mongo api using Mongichef
#fguigui: To help troubleshoot this, could you please re-rerun the same data migration operation using the command line option? Just launch dt.exe from the same folder as Data Migration Tool for syntax required. Then after you launch it with required parameters, please paste the output here and I'll take a look what's broken.
After reading the documentation I was expecting that this field is automatically set by Azure Mobile Services. Apparently it isn't.
Should I configure something extra?
Other options that I see (to do for each table):
* add an axtra line to the node js update(item, user, request) function:
item.__updatedAt = new Date();
* create an update trigger in the database
Anybody experience with this?
Thx!
The __updatedAt column is updated by a trigger created in the underlying SQL Server database, so it should be updated any time a row is updated. Note that this requires a database operation to occur for it to be updated.
The migration of the SQL Reporting component of Windows Azure from the old portal to the newer html 5 one has in the process limited the folder hierarchy to 2 levels deep (As indicated in this article).
The article does however state that existing reporting services can still have deeper hierarchies; whilst Business Intelligence Development Studio still allows you to deploy to the sub folder.
We have preserved our hierarchy like so:
Root Level
Client Reports
Internal Reports
Report Category 1
Data Source
Report1.rdl
Report2.rdl
Report Category 2
Due to the number of reports we have it is unfeasible to have every folder at root level and, thus far, the hierarchy has still be functioning correctly.
However we have run into a problem; we can no longer update any data sources or delete reports that are more than 2 levels deep.
Rather than restructure all our reports to suit what feels like an extremely restrictive structure, is there a way of managing our SQL Reporting reports external to the portal, via either an API, BIDS or Powershell?
OK so I've done a bit of research into this; SQL Reporting on Windows Azure exposes the ReportService2010 SOAP interface for administering the reports programmatically.
Using a proxy generated through the WSDL tool we can remotely connect to SQL Reporting using the below C# code:
var reportServiceUrl =
"https://X.reporting.windows.net/reportserver/reportservice2010.asmx?wsdl";
var serviceUsername = "AdminUserName;
var servicePassword = "AdminPassword";
var reportingService = new ReportingService2010
{
Url = reportServiceUrl,
CookieContainer = new CookieContainer()
};
reportingService.LogonUser(serviceUsername, servicePassword, reportServiceUrl);
The reportingService object can then be used to upload, update and delete all items on the SQL Reporting instance. If, for example, I wanted to delete a report in a sub folder that cannot be accessed on the Windows Azure portal, I could use:
reportingService.DeleteItem("Internal Reports/Report Category 1/Report1.rdl");
That stated; it is much easier to refactor the report folders to a 2 level hierarchy instead. The naming convention we ended up using is:
Root Level
Internal Reports - Report Category 1
Data Source
Report1.rdl
Report2.rdl
Internal Reports - Report Category 2
What I've done is broken the default 'Version' service on my WSO2 DSS, I tried to set the Scopes variable for WS-Discovery and didn't put a closing tag/element when creating the parameter.
Now when I try to access the parameters screen I get an xml Parse error
TID: [0] [WSO2 Data Services Server] [2012-08-22 12:38:04,404] ERROR {org.wso2.carbon.service.mgt.ServiceAdmin} - Error occured while getting parameters of service : Version
{org.wso2.carbon.service.mgt.ServiceAdmin}org.apache.axiom.om.OMException: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '<' (code 60) in end tag Expected '>'. at [row,col {unknown-source}]: [2,58] at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296) at
I'm assuming this is stored in the H2 database, I've tried looking for the parameter in the .db file using notepad but I can't find it.
Is there another way to connect/browse the H2 db?
I've scanned through the repository, database and conf directories for clues without success.
UPDATE:
Yes you can connect to the H2 db using the included database Explorer under the Tools menu.
Use the connection details found in the repository/conf/registry.xml file
Then you can do SQL queries on it - (I haven't found the answer yet though)
UPDATE 2:
I don't think the parameters are held in the H2 db, but I managed to fix my problem by:
downloading the Version.aar file using the link on the list services page
deleting the Version service
Copying the Version.aar file into the repository/deployment/server/axis2services dir
I guess deleting the service removed any records/references to my broken parameter
I believe you've tried setting service parameters via the UI? Usually the service parameters you specify via the UI do not get saved in the services.xml of the original axis2 service archive. Instead, they get saved in the registry that is shipped with DSS and get applied to the service at runtime. But if you specify a malformed parameter then wouldn't be saved in the registry instead, throwing an exception while trying to engage that parameter. So there'll be no record saved corresponding to that kind of malformed parameters.
Hope this helps!
Cheers,
Prabath