-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MicrosoftSQL.ExecuteQuery - Added handling of SqlGeoraphy objects #60
Conversation
WalkthroughThe pull request introduces updates to the Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 10
🧹 Outside diff range and nitpick comments (5)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs (2)
134-144
: Enhance test method robustness and documentation.Consider these improvements:
- Add XML documentation to describe the test's purpose and expectations
- Use a unique table name (e.g., with a GUID) to prevent conflicts
- Implement try-finally block for cleanup in case of test failure
+ /// <summary> + /// Tests the handling of SqlGeography data types using scalar execution. + /// Verifies the ability to create, insert, and select geography data. + /// </summary> [TestMethod] public async Task TestWithGeographyData_Scalar() { - var table = "geographytest"; + var table = $"geographytest_{Guid.NewGuid():N}"; + try + { var options = new Options() { SqlTransactionIsolationLevel = SqlTransactionIsolationLevel.None, CommandTimeoutSeconds = 2, ThrowErrorOnFailure = true };
134-178
: Consider adding test cases for invalid geography data.The test suite would benefit from additional test cases to verify proper handling of invalid scenarios:
- Invalid WKT format
- Invalid SRID
- Self-intersecting polygons
- Empty geometry collections
Would you like me to provide example test cases for these scenarios?
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs (2)
136-146
: Consider parameterizing test isolation levelThe test is hardcoded to use
SqlTransactionIsolationLevel.None
. Consider parameterizing this like the existingTestExecuteQuery_Auto
method to ensure geography operations work correctly across different isolation levels.
136-202
: Consider adding edge cases and error scenariosThe test covers the happy path but misses important edge cases:
- Invalid geography data
- NULL values
- Empty geometries
- Complex geometries (e.g., MultiPolygon)
- Different spatial reference systems (SRIDs)
Would you like me to provide example test cases for these scenarios?
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (1)
119-123
: Suggestion: Simplify type checking with theis
operatorInstead of using
GetType()
for type checking, consider using theis
operator for better performance and readability.Apply this diff to improve the type checking:
// JToken.FromObject() method can't handle SqlGeography typed objects so we convert it into string. -if (dataObject != null && dataObject.GetType() == typeof(SqlGeography)) +if (dataObject is SqlGeography) dataObject = dataObject.ToString();
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
Frends.MicrosoftSQL.ExecuteQuery/CHANGELOG.md
(1 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs
(1 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/Lib/ExecuteQueryTestBase.cs
(1 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs
(1 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs
(4 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.csproj
(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/Lib/ExecuteQueryTestBase.cs
🧰 Additional context used
🪛 LanguageTool
Frends.MicrosoftSQL.ExecuteQuery/CHANGELOG.md
[duplication] ~4-~4: Possible typo: you repeated a word
Context: ... Changelog ## [2.2.0] - 2024-11-26 ### Added - Added method to form JToken from the SqlDataR...
(ENGLISH_WORD_REPEAT_RULE)
🔇 Additional comments (6)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.csproj (2)
5-5
: LGTM! Version bump aligns with feature additions.
The version increment to 2.2.0 follows semantic versioning principles, appropriately reflecting the addition of SqlGeography support as a new feature.
27-27
: Verify Microsoft.SqlServer.Types package version and compatibility.
While the version matches the PR objectives, let's verify:
- If this is the latest stable version
- Any known security vulnerabilities
- Compatibility with existing dependencies (especially Microsoft.Data.SqlClient 5.2.1)
✅ Verification successful
Microsoft.SqlServer.Types package version 160.1000.6 is verified as secure and up-to-date
Based on the verification results:
- 160.1000.6 is currently the latest stable version available on NuGet
- No security vulnerabilities were found in the GitHub Security Advisory database
- The version follows the expected versioning pattern for SQL Server 2016+ compatibility (160.x.x)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check NuGet for latest versions and potential compatibility issues
# Check latest version from NuGet
curl -s https://api.nuget.org/v3-flatcontainer/microsoft.sqlserver.types/index.json | jq -r '.versions[]' | sort -V | tail -n 5
# Check if there are any GitHub security advisories
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: NUGET, package: "Microsoft.SqlServer.Types") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
# Check for compatibility documentation
fd -g "README*" -X grep -l "Microsoft.SqlServer.Types"
Length of output: 612
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (4)
10-10
: Approved: Addition of required namespace
The addition of using Microsoft.SqlServer.Types;
is necessary for handling SqlGeography
types.
106-106
: Approved: Utilizing LoadData
method for data reading
Replacing direct data loading with the LoadData
method enhances code modularity and readability.
128-128
: Approved: Consistent use of LoadData
method
Consistently using LoadData
for executing reader operations improves code maintainability.
177-198
: Verify necessity of handling multiple result sets
The use of while (reader.HasRows)
and await reader.NextResultAsync(cancellationToken)
indicates handling multiple result sets. Please confirm if multiple result sets are expected from the queries. If not, simplifying the code could improve readability and performance.
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs
Outdated
Show resolved
Hide resolved
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs (2)
175-177
: Enhance geography data validation assertions.While the current assertions verify the basic conversion and format, consider adding more comprehensive checks:
Assert.IsNotNull(select.Data["Value"], "Selected data should not be null"); Assert.IsInstanceOfType(select.Data["Value"], typeof(JValue), "Geography data should be converted to string"); Assert.IsTrue(((string)select.Data["Value"]).StartsWith("LINESTRING"), "First row should be a LINESTRING"); +// Verify coordinate values +var wkt = (string)select.Data["Value"]; +Assert.IsTrue(wkt.Contains("-122.360 47.656"), "Expected coordinates not found in WKT"); +Assert.IsTrue(wkt.Contains("-122.343 47.656"), "Expected coordinates not found in WKT"); +// Verify SRID +input.Query = "SELECT GeogCol1.STSrid FROM @TableName WHERE Id = 1"; +input.Parameters = new[] { new Parameter { Name = "@TableName", Value = table } }; +var sridResult = await MicrosoftSQL.ExecuteQuery(input, options, default); +Assert.AreEqual(4326, sridResult.Data["Value"], "Unexpected SRID value");
140-145
: Consider testing with different transaction isolation levels.The test only uses
SqlTransactionIsolationLevel.None
. Consider parameterizing the test to run with different isolation levels like theTestExecuteQuery_Scalar
method does.+foreach (var level in new[] { + SqlTransactionIsolationLevel.None, + SqlTransactionIsolationLevel.ReadCommitted, + SqlTransactionIsolationLevel.ReadUncommitted, + SqlTransactionIsolationLevel.Serializable +}) +{ var options = new Options() { - SqlTransactionIsolationLevel = SqlTransactionIsolationLevel.None, + SqlTransactionIsolationLevel = level, CommandTimeoutSeconds = 2, ThrowErrorOnFailure = true }; + // ... rest of the test ... +}Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs (1)
171-184
: Enhance geography data validationWhile the basic verification is good, consider strengthening it with SQL Server's geography methods:
- input.Query = $"SELECT * From {table}"; + input.Query = $@" + SELECT + Id, + GeogCol1, + GeogCol2, + GeogCol1.STAsText() as WKT, + GeogCol1.STSrid as SRID, + GeogCol1.STNumPoints() as NumPoints + FROM {table}"; var select = await MicrosoftSQL.ExecuteQuery(input, options, default); Assert.IsTrue(select.Success, "Select"); Assert.AreEqual(typeof(JArray), select.Data.GetType()); Assert.AreEqual(2, select.Data.Count); // Verify first row (LINESTRING) Assert.IsNotNull(select.Data[0]["GeogCol1"]); - Assert.IsTrue(select.Data[0]["GeogCol2"].ToString().StartsWith("LINESTRING")); + Assert.AreEqual(4326, select.Data[0]["SRID"]); + Assert.AreEqual(2, select.Data[0]["NumPoints"]); + Assert.AreEqual("LINESTRING (-122.36 47.656, -122.343 47.656)", select.Data[0]["WKT"]); // Verify second row (POLYGON) Assert.IsNotNull(select.Data[1]["GeogCol1"]); - Assert.IsTrue(select.Data[1]["GeogCol2"].ToString().StartsWith("POLYGON")); + Assert.AreEqual(4326, select.Data[1]["SRID"]); + Assert.AreEqual(5, select.Data[1]["NumPoints"]); + Assert.IsTrue(select.Data[1]["WKT"].ToString().Contains("-122.358 47.653"));Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (1)
177-179
: Consider performance optimizations for large datasetsTwo potential improvements for handling large datasets:
- Add cancellation check in the outer while loop
- Use StringBuilder for geography.ToString() when dealing with large geography objects
- while (reader.HasRows) + while (reader.HasRows && !cancellationToken.IsCancellationRequested) { while (await reader.ReadAsync(cancellationToken)) {- else if (fieldValue is SqlGeography geography) - value = geography.ToString(); + else if (fieldValue is SqlGeography geography) { + var builder = new StringBuilder(); + geography.ToString(builder); + value = builder.ToString(); + }Also applies to: 189-189
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs
(1 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs
(2 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs
(4 hunks)
🔇 Additional comments (7)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/ScalarUnitTests.cs (1)
4-4
: LGTM!
The added import is necessary for JValue type assertions in the geography data test.
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery.Tests/AutoUnitTests.cs (3)
136-154
: LGTM with existing suggestions!
The table creation logic has already been reviewed, and the suggestions from past reviews remain valid.
156-169
: Well-structured geography data insertion!
The implementation correctly:
- Uses appropriate SRID (4326) for WGS84 coordinate system
- Handles different geography types (LINESTRING and POLYGON)
- Includes proper error handling with try block
186-192
: LGTM - Proper test cleanup implementation!
The cleanup:
- Is properly placed in finally block ensuring it runs even if test fails
- Includes verification of successful table drop
- Follows test cleanup best practices
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (3)
10-10
: LGTM: Required import for SqlGeography support
The addition of Microsoft.SqlServer.Types import is necessary for handling SqlGeography objects.
106-107
: LGTM: Consistent handling of SqlGeography data across execution types
The changes appropriately handle SqlGeography objects by:
- Using the new LoadData method for both Auto and ExecuteReader types
- Converting SqlGeography to string for Scalar execution to prevent JToken serialization issues
Also applies to: 119-122, 128-129
174-202
: LGTM: Well-implemented data loading with optimized value handling
The LoadData method effectively implements the data loading logic with optimized value retrieval and type checking. The implementation properly handles:
- Multiple result sets
- Null values
- SqlGeography conversion
- Field name preservation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
Frends.MicrosoftSQL.ExecuteQuery/CHANGELOG.md (1)
5-6
: Consider clarifying the geography object handling improvementsThe changelog could be more specific about how these objects are now handled. Consider adding brief details about:
- The format/representation of the geography objects after processing
- Whether this is a breaking change for existing geography data handling
Example improvement:
- Added method to form JToken from the SqlDataReader so that SqlGeography and SqlGeometry typed objects can be handled. - Fixed how Scalar handles the data so that SqlGeography and SqlGeometry typed objects can be handled. + Added method to serialize SqlGeography and SqlGeometry objects to WKT format when forming JToken from SqlDataReader. + Enhanced Scalar method to properly serialize SqlGeography and SqlGeometry objects to their WKT representation.Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (2)
119-123
: Consider combining type checks for better readabilityWhile the handling is correct, the type checking could be more concise.
Consider this improvement:
- if (dataObject != null && (dataObject.GetType() == typeof(SqlGeography) || dataObject.GetType() == typeof(SqlGeometry))) + if (dataObject is SqlGeography or SqlGeometry) dataObject = dataObject.ToString();
174-204
: LGTM: Well-implemented data conversion with proper handlingThe LoadData method is well-structured with proper handling of:
- Multiple result sets
- Null values
- Type conversions
- Cancellation
For large result sets, consider adding a batch size option to control memory usage. This could be implemented by:
- Adding a BatchSize parameter to Options
- Yielding batches of rows when the batch size is reached
- Allowing streaming processing of large datasets
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
Frends.MicrosoftSQL.ExecuteQuery/CHANGELOG.md
(1 hunks)Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs
(4 hunks)
🧰 Additional context used
🪛 LanguageTool
Frends.MicrosoftSQL.ExecuteQuery/CHANGELOG.md
[duplication] ~4-~4: Possible typo: you repeated a word
Context: ... Changelog ## [2.2.0] - 2024-11-26 ### Added - Added method to form JToken from the SqlDataR...
(ENGLISH_WORD_REPEAT_RULE)
🔇 Additional comments (3)
Frends.MicrosoftSQL.ExecuteQuery/CHANGELOG.md (1)
7-7
: Verify Microsoft.SqlServer.Types dependency version
Let's verify if version 160.1000.6 is the latest stable version and check for any known security issues.
✅ Verification successful
Version 160.1000.6 is the latest stable release of Microsoft.SqlServer.Types
The version specified in the changelog (160.1000.6) is indeed the latest stable release available on NuGet, and there are no known security vulnerabilities reported for this package. The dependency version choice is appropriate.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check latest version and security advisories for Microsoft.SqlServer.Types
# Check NuGet for latest versions
curl -s https://api.nuget.org/v3/registration5-semver1/microsoft.sqlserver.types/index.json | jq -r '.items[0].items[].catalogEntry.version'
# Check for security advisories
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: NUGET, package: "Microsoft.SqlServer.Types") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
Length of output: 649
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (2)
10-10
: LGTM: Required dependency added for SqlGeography support
The addition of Microsoft.SqlServer.Types is correctly placed and aligns with the PR objectives.
Line range hint 1-205
: Verify complete SqlGeography handling and error message consistency
Let's ensure all SqlGeography/SqlGeometry handling cases are covered and error messages are consistent.
✅ Verification successful
SqlGeography/SqlGeometry handling is complete and error messages are consistent
The verification shows:
- SqlGeography/SqlGeometry types are properly handled in both scenarios:
- In scalar execution: Converting to string before JToken.FromObject()
- In data reader: Using pattern matching to convert both types to string
- Error messages follow a consistent pattern across all Microsoft SQL tasks:
- Main exceptions: "{TaskName} exception: {ex}"
- Transaction-related messages use identical wording across tasks
- Rollback exceptions maintain the same format with both the rollback error and original exception
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any missed SqlGeography/SqlGeometry handling
rg -A 2 "SqlGeography|SqlGeometry" --type cs
# Check error message consistency
rg "exception:" --type cs
Length of output: 7992
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (1)
178-207
: Consider performance optimizations for large datasetsThe LoadData implementation correctly handles SqlGeography/SqlGeometry types and multiple result sets. However, for large datasets, consider these optimizations:
Apply this diff to improve performance:
private static async Task<JToken> LoadData(SqlDataReader reader, CancellationToken cancellationToken) { var table = new JArray(); + // Cache field count and names outside the loops + var fieldCount = reader.FieldCount; + var fieldNames = Enumerable.Range(0, fieldCount) + .Select(i => reader.GetName(i)) + .ToArray(); + while (reader.HasRows) { + // Pre-size the array if possible + var rows = new List<JObject>(); while (await reader.ReadAsync(cancellationToken)) { var row = new JObject(); - for (var i = 0; i < reader.FieldCount; i++) + for (var i = 0; i < fieldCount; i++) { object fieldValue = reader.GetValue(i); object value; if (fieldValue == DBNull.Value) value = null; else if (fieldValue is SqlGeography geography) value = geography.ToString(); else if (fieldValue is SqlGeometry geometry) value = geometry.ToString(); else value = fieldValue; - row.Add(new JProperty(reader.GetName(i), value)); + row.Add(new JProperty(fieldNames[i], value)); } - table.Add(row); + rows.Add(row); } + table.AddRange(rows); await reader.NextResultAsync(cancellationToken).ConfigureAwait(false); } return table; }These optimizations:
- Cache field count and names to reduce method calls
- Use List for batch adding rows
- Reduce JProperty creation overhead
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs
(4 hunks)
🔇 Additional comments (4)
Frends.MicrosoftSQL.ExecuteQuery/Frends.MicrosoftSQL.ExecuteQuery/ExecuteQuery.cs (4)
10-10
: LGTM: Required import for SqlGeography support
The addition of Microsoft.SqlServer.Types is necessary for handling SqlGeography and SqlGeometry types.
105-106
: LGTM: Consistent use of new LoadData method
The changes properly integrate the new LoadData method while maintaining correct async patterns and reader disposal.
Also applies to: 127-128
171-176
: LGTM: Proper resource cleanup
The finally block ensures proper cleanup of the SqlDataReader resource.
118-122
:
Add null check before ToString() call
While checking for SqlGeography/SqlGeometry types, ensure the object isn't null before calling ToString().
Apply this diff to add null safety:
if (dataObject != null && (dataObject.GetType() == typeof(SqlGeography) || dataObject.GetType() == typeof(SqlGeometry)))
- dataObject = dataObject.ToString();
+ dataObject = dataObject?.ToString();
Likely invalid or redundant comment.
#59
[2.2.0] - 2024-11-26
Added
Summary by CodeRabbit
Release Notes for Frends.MicrosoftSQL.ExecuteQuery Version 2.2.0
New Features
JToken
fromSqlDataReader
, enhancing data handling forSqlGeography
andSqlGeometry
types.SqlGeography
in scalar queries.Bug Fixes
Chores
Microsoft.SqlServer.Types
for improved functionality.