I'm at my first tries with the TFS SDK (Microsoft.TeamFoundation.VersionControl.Client) and when came time to retrieve objects, I got confused on why and when I should use VersionControlServer.GetItems vs VersionControlServer.GetExtendedItems. What are the differences? Performance? Features?
Thank you! :)
Yes, you have a tradeoff between performance and features. You can imagine that GetItems is a simple query, whereas GetExtendedItems is a join on another table (or tables), and less efficient.
An Item, for example, contains information about an item at a particular version. An ExtendedItem adds in information about your version of that file as it exists in the workspace that you've specified in the query. If you have done a Get on that file then fields will be populated with the version that exists on your local disk and any pending changes that you've made on it.
ExtendedItems largely exist for the Source Control Explorer view; it can display information about both the items on the server and their status in your local repository in a single query. This reduces the number of round-trips that view makes, but the ExtendedItems query is more expensive than a query for simple Items.
If GetItems will give you the data that you need, you should prefer that. If not, use GetExtendedItems.
I need to add tag reporting capability to a collection of custom SSRS reports which query TFS_Warehouse (and in one case I had to query the operational store to gather test case steps). These reports all use a SQL Server datasource connected to my custom TFS_Warehouse_Extensions database.
If this sounds familiar, I asked this question yesterday and got a wonderful response... then I discovered we upgraded from 2013 to 2015 last week and dbo.workitemsare is gone.
I am using VS 2015 and am more of a database developer than a C# programmer (I know just enough to be dangerous). Is there any way I can get tags from TFS 2015 workitems into my SSRS reports?
Edit: the proposed duplicate answer is not exactly the same problem. Whether or not some work items views went missing is ancillary. My requirement is for a way to query TFS tags in SSRS. So far I consider this unanswered in either thread since no one has proposed a solution that meets the requirement.
#Cyndi, I'm a Program Manager with the reporting team. Currently reporting with Tags is not supported aside from queries with the query editor. We do have a new reporting solution we're working on and reporting on tags will be supported. I don't have an exact date for the release yet, but see this blog post for some details. We'll have more announcements to make this summer.
One totally diffrent way would be to use Excel for reporting.
You build a query in TFS and then connect Excel to TFS and use the query. The functionality is kind of limited, but you can use Excels features to make great reports.
One problem with Excel is that you can't (you shouldn't) add further fields to the table you got from TFS. When you update the data, Excel will lock up and nothing happens.
If you need to use custom fields for your reporting, you should create a second table, where all the data is copied to. This can be as well automated with VBA.
That data can be analysed directly in the table or with a Pivot Table or visualised a Pivot Chart.
With the use of the Pivot feature Excel is able to create powerful reports.
It's not a good idea to query the operational store. This may cause some problems for normal usage.
You should NEVER write reports directly against the WorkItem* tables
in the collection database, since this is an operational store and is
100% unsupported and can cause performance problems for normal usage.
Source: How to query Work Items using SQL on the Relational Warehouse
Programming Language: Delphi 6
SQL Server in The Back end.
Problem:
Application used to hit DB each time we needed something , Ended up hitting it for more than 2000 times for getting certain things, Caused problems with application being slow. This hitting DB happened for a lot of tables each having different structure and different number of columns. So I’m trying to reduce the number of calls.
We can have about 4000 records at a time from each table.
Proposed Solution:
Let’s get all the data from DB at once and use it when we need it so we don’t have to keep hitting the DB.
How Solution is turning out so far:
This version of Delphi doesn’t have a dictionary. So we already have an implementation of a dictionary from String List (Let us assume that implementation is good).
Solution 1:
Store this in a dictionary that we created with:
A unique field as a key.
And Add rest of the data as strings in String List separated like this:
FiledName1:FileValue,FieldName2:FieldValue2,…..
Might Have to create about 2000 String List to map data to key.
I took a look at the following link:
How Should I Implement a Huge but Simple Indexed StringList in Delphi?
Looks like they could move to a different DB not possible with me.
Is this a sane solution?
Solution 2:
Store this in a dictionary with List.
That list will have Delphi Records.
Records can’t directly be added to so I took a look at this Link:
Delphi TList of records
Solution 3:
Or Given that I’m using TAdoQuery should I use Seek or locate to find my records.
Please advice on the best way to do this?
Requirements:
Need Random Access of this data.
Insertion of data will happened only once when we get all the data , per table as we require them.
Need to only read the data , don’t have to modify it.
Constantly need to search in terms of primary key.
In addition to changing the application we have already done good indexing on DB to take care of things from DB side. This is more to make things run well from the application.
This sounds like a perfect use case for TClientDataSet. It's an in-memory dataset that be indexed, filtered, and searched easily, hold any information you can retrieve from the database using a SQL statement, and it has pretty good performance over a few thousand reasonable-sized rows of data. (The link above is to the current documentation, as I don't have one available for the Delphi 6 docs. They should be very similar, although I don't recall which specific version added the ability to directly include MidasLib in your uses clause to eliminate distributing Midas.dll with your app.)
Carey Jensen wrote a series of articles about it a few years back that you might find useful. The first one can be found in A ClientDataset in Every Database Application - the others in the series are linked from it.
is there any way to link 2 stored procedures in a crystal reports?
I read that a stored procedure cannot call another stored procedure in a crystal report?
You should be able to do so in either the database 'expert' or within a command. However, the JOIN will be done in Crystal Reports WhileReadingRecords.
If that doesn't work for some reason, embed the second SP in a subreport, then link the main report to the subreport.
Neither of these approaches are terribly efficient. You should consider combining the queries in a way that they can be used by CR in an efficient manner.
Stored procedures, in my opinion, should be avoided in reporting, as they:
add complexity
increase maintenance costs
don't result in significant performance gains when compared to a well-structured query
I need to read from and write to Excel spreadsheets using Delphi 2010. Nothing fancy. Just reading and writing values from specific cells and ranges on different sheets. Needs to work without having Excel installed and support Excel 2007.
Some things I've looked at:
I've tried using ADO, which works OK for selecting everything in an entire sheet, but I haven't had much luck reading specific cells or ranges.
NativeExcel looked promising, but it doesn't seem to be in active development, and they don't respond to e-mails.
Axolot has a couple of products. The main product seems to be very functional, but is pricey. They have a lite version, but it doesn't support Delphi 2010.
Any recommendations? Free would be great, but I'm open to a commercial solution as long as it's reliable and well supported.
TMS Flexcel - I know it looks like a reporting component for Excel (which it does very well and is a very handy tool to have in your toolkit) but it also includes components for reading and displaying Excel files. I've been very impressed with how well Adrian Gallero seems to know the Excel API, including Excel 2007.
http://www.tmssoftware.com/site/flexcel.asp
Not free of course, but at 75 Euros I think it's good value.
I've had very good luck with ADO, provided the Excel sheet is a fairly straight-forward row/column layout.
The key with using ADO, I've found, is treating the Excel sheet like a database. If your Excel sheets are primarily straight row and column layouts, just treat the rows as database records and the columns as fields. Navigate to the desired row first by searching for a particular column (field) value (preferably something unique), and then read the desired cell in that row by referencing the field that is the column name.
If your Excel sheets are more free-form, then it will be more difficult.
Don't write off NativeExcel. I have used it for a couple of years now with excellent results. It's fast and versatile. I use it to produce a nicely formatted multi-page spreadsheet with frozen panes, formulas in cells, and data from a client's database for them to use for input and then send back to me. My clients were really thrilled when they got the first spreadsheet from me because it reduced their workload tremendously and it was fairly intuitive for them to use.
I don't know why they have not responded to you because I have updated their package at least a couple of time over the last two years. When my license expires, I definitely intend to renew.
I'd recommend SMImport / SMExport from http://www.scalabium.com
Mike has always been really helpful and quick to respond.
What really helps is if you have some kind of control over the layout of the excel file.
I have built a whole unit and acceptance testing framework where the data and the test controls are all contained within an Excel spreadsheet.
I did everything through ADO. You can restrict your ADO SQL query to a whole sheet, a named range or any range for the matter. In my opinion and experience, this method is very powerful.
Two things that did cause me some problems :
1. depending on how your sheets are named, ADO might or might not see them (again, if you have control over the layout, great !)
2. be careful about the data type ADO returns when you read data i.e. it might show numbers as strings. This is because ADO tries, IIRC, to guess the data type based on the first few rows.
Disclaimer : I have never used any of the tools mentioned above. ADO did the trick for me, and I feel more in control since I wrote the code for my framework (save the ADO part obviously...).
Bruce, I've used the Axolot XLSReadWriteII component for going on 10 years now. It's been very good, and their support forums (while lite on content) seem to be monitored pretty well. The XLSReadWriteII2 version is blindingly fast, and supports all sorts of things like charts and graphics, named ranges, adding formulas on the fly, cell formatting (including borders and shading, merging cells, vertical and horizontal alignment, auto-width column sizing, and so forth).
I haven't upgraded to the latest version (we're still using XLSReadWriteII2) because we can still use the Excel XP format files, and I haven't used the XLSMini at all. I can say really good things about the full product, though; in fact, I just used it for a couple of database export things this past week.
If you decide to go that route, I have a bunch of notes about how to do different things that might be useful; if you want them, drop me a note. I also have a Delphi 2007 app that just shows how to do different formatting and alignments; I actually reproduced an existing, fairly complex report in Excel complete with all of the formats, borders, etc. that I'd be glad to let you have as well.
DISCLAIMER: I have no connection with Axolot or any of their employees. I'm just a very happy customer who learned of the product at a previous job, and was impressed enough to buy it when I started my current one.
Don't bother with Axolot's XLSMini (lite) version. I haven't purchased either of them yet, but I asked about Excel 2007 support in early 2008 and Lars told me XLSMini was based on the XLSReadWriteII and that both would be updated with Excel 2007 support at the same time. XLSReadWriteII has had Excel 2007 support since April 2008; XLSMini still doesn't have it.
With great luck, I've used Axolot for some years now. The support forum isn't exactly brimming with messages, but maybe that's because it works so well?
You can use ADO connection string like
http://www.connectionstrings.com/excel
than include the options (in the third tab of ado connection string):
Extended Properties=Excel 8.0;HDR=Yes;IMEX=0
for security purposes Microsoft prevent modifications (with IMEX=1)
http://support.microsoft.com/kb/904953/en
Sample SQL (don't forget the brackets):
SELECT * FROM [Sheet1$]
The only thing you can't do, is deletion:
http://support.microsoft.com/kb/257819/en
So to delete a row make it empty!
You can also use SQL via ADO to export:
YourADOConnection.Execute('SELECT * INTO aSheet IN "'+ExtractFilePath(ParamStr(0))+'Exported.xls" "Excel 8.0;" FROM YourTable');
I would advise to go for an option where you don't need Excel installed on the machine. I once used a component that could easily fill in some data in one sheet without needing excel installed. I would also do most of the Excel work in the Excel sheet itself. And just use the components to fill in some data on the sheet.
My 2cts.