Latest Contributions by SasaI_

Thank you for identifying this issue which was also picked up by our own internal performance tests.  We've duplicated the problem and have a solution.  The issue was due to the addition of the IsEditable check to block the modification of features with advanced geodatabase behavior.  The fix will be available in the Final code drop for the File API. Thank you Lance.  I figured it may have something to do with the IsEditable check, as there was nothing else mentioned in beta3 updates that should have had any effect on the code.  I'm glad its a bug that will be fixed, and not just something we have to live with. ... View more

More test results.  This time I've compiled it for both x86/x64 and compiled it against the debug and release library versions.  Tests are writing 10k lines each with 1 part and 6 vertices, then deleting all lines. Beta 2: Win32 Debug: Wrote 10000 to the database (total of 60000 points) in 1.894s Finished deleting all rows, time taken: 1.372s x64 Debug: Wrote 10000 to the database (total of 60000 points) in 1.078s Finished deleting all rows, time taken: 0.806s Win32 Release: Wrote 10000 to the database (total of 60000 points) in 0.424s Finished deleting all rows, time taken: 0.397s x64 Release: Wrote 10000 to the database (total of 60000 points) in 0.311s Finished deleting all rows, time taken: 0.317s Beta 3: Win32 Debug: Wrote 10000 to the database (total of 60000 points) in 7.247s Finished deleting all rows, time taken: 7.061s Win32 Release: Wrote 10000 to the database (total of 60000 points) in 4.394s Finished deleting all rows, time taken: 4.734s x64 Debug: Wrote 10000 to the database (total of 60000 points) in 5.436s Finished deleting all rows, time taken: 5.285s x64 Release: Wrote 10000 to the database (total of 60000 points) in 4.898s Finished deleting all rows, time taken: 5.301s ... View more

Which Visual Studio? 32-bit or 64-bit? Are you using the Release or Debug libraries? Are the jobs run on the same machine with identical load? Why do the Beta-2 and Beta-3 passes have different numbers of vertices?  How large are the directories before you start delete operations? What happens if you use the Beta-2 shape creation protocol with the Beta-3 API DLL (one variable test)? - V Visual Studio 2008 v9.0.30729.4462 QFE (32bit) running on Windows 7 64bit.  Projects are compiled as 32-bit projects against the Debug libraries.  Jobs are run on the same machine with an identical load.  The reason for the different number of vertices in the second run is because the test creates 10k polylines, each with 1 part and a random number of vertices per part (2-3 in the first run for both, 2-10 in the second run). For sake of comparing apples to apples, I re-wrote the test to write 10k polylines, each with 1 part.  The first test writes 2 vertices per part for a total of 20k points, the second writes 6 vertices per part for a total of 60k points.  I've posted both the results and the code I use to test.  I'd be more than happy to hear about any improvements to the code that I can as I'm definitely not a highly experienced C++ programmer (I come from a C# background).  As with the previous tests, both of the tests write to the same copy of the database (I created an original and make a copy of the clean original for each test run).  I've tried running the test a number of times, each time receiving results that vary by less than 0.5s in case of beta 3, and around 0.25s for beta 2.  Apparently I didn't install X64 Compilers and Tools when I installed VS2008 so I can test with 64bit until I install the component, but when I do I will re-run the test. Here are the results: Beta 2: Wrote 10000 to the database (total of 20000 points) in 1.955s Finished deleting all rows, time taken: 1.385s Wrote 10000 to the database (total of 60000 points) in 2.057s Finished deleting all rows, time taken: 1.422s Beta 3: Wrote 10000 to the database (total of 20000 points) in 8.042s Finished deleting all rows, time taken: 7.591s Wrote 10000 to the database (total of 60000 points) in 8.094s Finished deleting all rows, time taken: 7.729s Here's the code snippet I use to create the lines in beta 2: int numPoints = 6; int numParts = 1; int partIdx = 0; unsigned long length = 48 + numPoints * 16; int totPoints = 0; int totLines = 10000; int shapetype = 3; wcout << "Testing with " << totLines << " lines." << endl; Row r; ShapeBuffer geom; clock_t start = clock(); for (int i=0; i<totLines; i++) { table.CreateRowObject(r); r.SetString(L"TextField", L""); r.SetDouble(L"DoubleField1", 0.0); r.SetDouble(L"DoubleField2", 0.0); r.SetNull(L"DateField"); r.SetInteger(L"IntegerField1", 0); r.SetInteger(L"IntegerField2", 0); geom.Allocate(length); memcpy(geom.shapeBuffer, &shapetype, sizeof(shapetype)); // Shapetype memcpy(geom.shapeBuffer + 36, &numParts, sizeof(numParts)); // Number of parts memcpy(geom.shapeBuffer + 40, &numPoints, sizeof(numPoints)); // Number of points memcpy(geom.shapeBuffer + 44, &partIdx, sizeof(partIdx)); // Fist (and only) part index double minx = 180, miny = 90, maxx = -180, maxy = -90; rand(); for (int j=0; j<numPoints; j++) {   totPoints++;   double x = -180.0 + rand() * (360.0) / RAND_MAX;   double y = -90.0 + rand() * (180.0) / RAND_MAX;   if (x < minx) minx = x;   if (x > maxx) maxx = x;   if (y < miny) miny = y;   if (y > maxy) maxy = y;   memcpy(geom.shapeBuffer + 48 + j*2*sizeof(double), &x, sizeof(double)); // X   memcpy(geom.shapeBuffer + 48 + j*2*sizeof(double)+sizeof(double), &y, sizeof(double)); // Y } // Copy the extent memcpy(geom.shapeBuffer + 4, &minx, sizeof(double)); memcpy(geom.shapeBuffer + 12, &miny, sizeof(double)); memcpy(geom.shapeBuffer + 20, &maxx, sizeof(double)); memcpy(geom.shapeBuffer + 28, &maxy, sizeof(double)); geom.inUseLength = length; r.SetGeometry(geom); // Store the row. if ((hr = table.Insert(r)) != S_OK) {   wcout << "An error occurred while inserting a row." << endl;   wcout << "Error code: " << hr << endl;   return -1; } } time_t delstart = clock(); wcout << "Wrote " << totLines << " to the database (total of " << totPoints << " points) in " << (delstart - start)/1000.0 << "s" << endl; And the similar code for beta 3: int numPoints = 6; int numParts = 1; int partIdx = 0; int totPoints = 0; int totLines = 10000; int shapetype = 3; wcout << "Testing with " << totLines << " lines." << endl; Row r; MultiPartShapeBuffer geom; clock_t start = clock(); for (int i=0; i<totLines; i++) { table.CreateRowObject(r); r.SetString(L"TextField", L""); r.SetDouble(L"DoubleField1", 0.0); r.SetDouble(L"DoubleField2", 0.0); r.SetNull(L"DateField"); r.SetInteger(L"IntegerField1", 0); r.SetInteger(L"IntegerField2", 0); hr = geom.Setup(shapetype, numParts, numPoints, 0); Point* points; hr = geom.GetPoints(points); for (int j=0; j<numPoints; j++) {   totPoints++;   points .x = -180.0 + rand() * (360.0) / RAND_MAX;   points .y = -90.0 + rand() * (180.0) / RAND_MAX; } geom.CalculateExtent(); r.SetGeometry(geom); // Store the row. if ((hr = table.Insert(r)) != S_OK) {   wcout << "An error occurred while inserting a row." << endl;   ErrorInfo::GetErrorDescription(hr, errorText);   wcout << errorText << "(" << hr << ")." << endl;   return -1; } } time_t delstart = clock(); wcout << "Wrote " << totLines << " to the database (total of " << totPoints << " points) in " << (delstart - start)/1000.0 << "s" << endl; ... View more

Just to add to the above findings.  I tested writing lines this morning, and found similar issues.  The speed isn't largely affected by the number of points written, the slowdown is mainly in the number of features written (this is true for beta 2 and beta 3 releases, and makes perfect sense). Beta 2 Timings: Wrote 10000 polylines to the database (total of 25006 points) in 2,554.00ms Wrote 10000 polylines to the database (total of 59854 points) in 2,462.00ms Beta 3 Timings: Wrote 10000 polylines to the database (total of 25005 points) in 9,871.00ms Wrote 10000 polylines to the database (total of 60040 points) in 10,348.00ms ... View more

Thanks everyone for the comments. I've updated the wrapper to use FileGDBAPI beta 3 release.  A couple of the tests still fail, so I have not created a src/bin download yet (you'll need to grab the latest changes from the svn trunk).  I will fix the remaining bugs over the next couple days and add a new download for version 0.3. ... View more

I've done a number of updates to the code which includes implementing (almost) all API functionality, various bug fixes, and addition of a test project (both for testing and for illustrating how to use the wrapper).  I've also added the source and bin downloads to the Google code project. Project home is http://code.google.com/p/filegdb-dotnet-wrapper/ Code downloads can be found at http://code.google.com/p/filegdb-dotnet-wrapper/downloads/list ... View more

I just replied to the .NET Wrapper thread with this, but here is the summary: It seems you must prefix the table name with a "\".  So in case of the ExecuteSQL.gdb database, if you want to open the cities table you'll want to make the call as OpenTable(L"\\Cities").  If you don't prefix the path with a "\", the table opens successfully AND the table definition is populated properly from the GetDefinition call.  However, the result code is -2147211775, indicating the path is not found.  Prefixing the table will make the function return 0. This is made even more confusing with the samples opening the table by using both L"Cities" (Display/Querying) and L"\\Cities" (Editing). ... View more

I edited a local copy of your code in 'SQLTest' by adding this .... ... TableNet table = gdbnet.OpenTable("Cities"); string xml = table.GetDefinition(); -> ERROR ERROR ERROR ... If you make the OpenTable call with "\\Cities" as the table name (i.e. explicitly specify no parent), then the definition is grabbed and result is 0.  If you open the table with "Cities" as the table name, then the definition is grabbed but result is -2147211775 (ITEM_NOT_FOUND).  I'm not entirely sure if this is a bug or if it simply isn't documented properly.  If you look at documentation of some other functions, such as Geodatabase->GetChildDatasets/GetRelatedDatasets, it notes that path should be specified as "\usa", which leads me to believe that all paths should have a leading "\" specified.  Not sure why they still end up fetching the table definition even in case you don't have a leading "\".  If you debug the code and look at contents of the string variable passed to Table->GetDefinition you'll notice that it is populated with the table definition, even though the result indicates it couldn't find the table. Thanks for noticing the bug.  I'll commit more tests and code updates today. ... View more

Hm, very odd, the latest commit (at least I think I committed it) worked fine.  I'll check it out tomorrow and post an update. ... View more

Its a dojo bug with a fairly simple workaround.  Check out http://bugs.dojotoolkit.org/ticket/10491 for more information. ... View more

I use ArcObjects in a web service to get a collection of related records in 9.3.1 (10 is a LOT simpler).  Here's a code snippet: IRelationshipClassCollection relClassCollection = (IRelationshipClassCollection)fl; IEnumRelationshipClass relClasses = relClassCollection.RelationshipClasses; IRelationshipClass rc = null; while ((rc = relClasses.Next()) != null) {     ISet relSet = rc.GetObjectsRelatedToObject(f);     IRowBuffer rowBuffer = null;     while ((rowBuffer = (IRowBuffer)relSet.Next()) != null)     {... where fl is your IFeatureLayer and f is your IFeature you want to get records for. ... View more