3 results found

1. Executing SQL with named parameters causes a dialog to show up asking for the parameters.

   If I have the following SQL:

   EXEC sp_rename @objname='ardbPcbRelatedGames.PcbRelatedGamesID', @newname='PcbRelatedGameID', @objtype='COLUMN'

   A dialog will pop up asking for the values for @objname, @newname and @objtype. Those already have values provided and it doesn't need to ask me for them.

   3 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   under review  ·  1 comment  ·  Bugs  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Default column for datetime added getdate() as default.

   It will not save that column. I get an error about the )

   1 vote

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   under review  ·  2 comments  ·  Bugs  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Results Grid truncates fractional seconds and ignores SQL Server datetime precision

   Summary
   Data grid does not display fractional seconds in the Results Grid according to the actual precision defined by SQL Server datetime datatypes. The grid appears to default to millisecond display regardless of the underlying column scale.

   Problem Description
   SQL Server supports multiple datetime-related datatypes, each with well-defined precision and storage semantics:

   smalldatetime (minute precision)
   datetime (fixed, ~3.33 ms increments)
   datetime2(p) where p = 0 through 7
   datetimeoffset(p) where p = 0 through 7
   expressions such as AT TIME ZONE, which return datetimeoffset(7)

   In dbForge Studio for SQL Server version 2025.2.138, the Results Grid does not display fractional seconds based on the actual datatype precision. Instead, values are rendered as if they were millisecond-based, even when the underlying column type is datetime2(5), datetime2(7), or datetimeoffset(7).

   As a result, higher precision stored in SQL Server is visually truncated in the grid, which is misleading. All datetime values appear to show only 3 fractional digits. Higher precision values (5 or 7 digits) are not displayed. No visible distinction between datetime2(3) and datetime2(7)

   Expected Behavior
   The Results Grid should display fractional seconds based on the actual SQL Server datatype precision, for example:

   smalldatetime: no fractional seconds
   datetime: SQL Server-defined millisecond resolution
   datetime2(0): no fractional seconds
   datetime2(3): 3 fractional digits
   datetime2(5): 5 fractional digits
   datetime2(7): 7 fractional digits
   datetimeoffset(7): 7 fractional digits plus timezone offset

   This matches the behavior of SQL Server Management Studio and Azure Data Studio and is critical for accurate inspection of time-sensitive data.

   Reproduction Transact-SQL code:

   SET NOCOUNT ON;
   
   IF OBJECT_ID('tempdb..#TestDates') IS NOT NULL
       DROP TABLE #TestDates;
   
   CREATE TABLE #TestDates
   (
       RowId int IDENTITY(1,1) PRIMARY KEY,
       Dt_smalldatetime smalldatetime,
       Dt_datetime datetime,
       Dt_datetime2_0 datetime2(0),
       Dt_datetime2_3 datetime2(3),
       Dt_datetime2_5 datetime2(5),
       Dt_datetime2_7 datetime2(7),
       Dt_datetimeoffset_7 datetimeoffset(7)
   );
   
   INSERT INTO #TestDates
   (
       Dt_smalldatetime,
       Dt_datetime,
       Dt_datetime2_0,
       Dt_datetime2_3,
       Dt_datetime2_5,
       Dt_datetime2_7,
       Dt_datetimeoffset_7
   )
   VALUES
   (
       CAST('2026-02-03T14:32:00' AS smalldatetime),
       CAST('2026-02-03T14:32:10.123' AS datetime),
       CONVERT(datetime2(0), '2026-02-03T14:32:10', 126),
       CONVERT(datetime2(3), '2026-02-03T14:32:10.123', 126),
       CONVERT(datetime2(5), '2026-02-03T14:32:10.12345', 126),
       CONVERT(datetime2(7), '2026-02-03T14:32:10.1234567', 126),
       TODATETIMEOFFSET(CONVERT(datetime2(7), '2026-02-03T14:32:10.1234567', 126), '+00:00')
   );
   
   -- What the data grid displays by default
   SELECT
       RowId,
       Dt_smalldatetime,
       Dt_datetime,
       Dt_datetime2_0,
       Dt_datetime2_3,
       Dt_datetime2_5,
       Dt_datetime2_7,
       Dt_datetimeoffset_7
   FROM #TestDates;
   
   -- what is expected to be shown in the data grid
   SELECT
       RowId,
       CONVERT(varchar(50), Dt_smalldatetime, 126) AS SmallDt_rounded_minute_precision,
       CONVERT(varchar(50), Dt_datetime, 126) AS Dt_datetime_quantized,
       CONVERT(varchar(50), Dt_datetime2_0, 126) AS Dt2_0_expected_0_digits,
       CONVERT(varchar(50), Dt_datetime2_3, 126) AS Dt2_3_expected_3_digits,
       CONVERT(varchar(50), Dt_datetime2_5, 126) AS Dt2_5_expected_5_digits,
       CONVERT(varchar(50), Dt_datetime2_7, 126) AS Dt2_7_expected_7_digits,
       CONVERT(varchar(50), Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time', 126) AS Central_expected_iso,
       DATEPART(TZOFFSET, Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time') AS Central_expected_tzoffset_minutes
   FROM #TestDates;
   
   -- show precision for each datatype
   SELECT
       RowId,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_smalldatetime), 'Scale') AS Scale_smalldatetime,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime), 'Scale') AS Scale_datetime,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_0), 'Scale') AS Scale_datetime2_0,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_3), 'Scale') AS Scale_datetime2_3,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_5), 'Scale') AS Scale_datetime2_5,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7), 'Scale') AS Scale_datetime2_7,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetimeoffset_7), 'Scale') AS Scale_datetimeoffset_7
   FROM #TestDates;
   
   -- show basetype and precision for explicit conversions in SELECT
   SELECT
       RowId,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7), 'BaseType') AS BaseType_dt2_7,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7), 'Scale')    AS Scale_dt2_7,
   
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC'), 'BaseType') AS BaseType_utc_as_dto,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC'), 'Scale')    AS Scale_utc_as_dto,
   
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time'), 'BaseType') AS BaseType_central_as_dto,
       SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time'), 'Scale')    AS Scale_central_as_dto
   FROM #TestDates;
   
   IF OBJECT_ID('tempdb..#TestDates') IS NOT NULL
       DROP TABLE #TestDates;
   

   Why This Matters

   Developers rely on the Results Grid to debug ordering, uniqueness, and event timing
   Truncated display can falsely suggest rounding or data loss
   This is especially problematic for telemetry, logging, and distributed systems
   Displaying fewer fractional digits than are stored is misleading, even if the underlying value is correct

   Request
   Please restore or add functionality so that the Results Grid:

   Displays fractional seconds based on the actual SQL Server datatype precision
   Correctly distinguishes between datetime, datetime2(p), and datetimeoffset(p)
   Applies this behavior consistently to table columns, computed expressions, and AT TIME ZONE results
   Optionally allows overriding the display format, but defaults to datatype-accurate rendering

   Environment
   dbForge Studio for SQL Server: 2025.2.138
   SQL Server version: 2017

   Summary
   Data grid does not display fractional seconds in the Results Grid according to the actual precision defined by SQL Server datetime datatypes. The grid appears to default to millisecond display regardless of the underlying column scale.

   Problem Description
   SQL Server supports multiple datetime-related datatypes, each with well-defined precision and storage semantics:

   smalldatetime (minute precision)
   datetime (fixed, ~3.33 ms increments)
   datetime2(p) where p = 0 through 7
   datetimeoffset(p) where p = 0 through 7
   expressions such as AT TIME ZONE, which return datetimeoffset(7)

   In dbForge Studio for SQL Server version 2025.2.138, the Results Grid does not display fractional seconds based… more

   1 vote

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   under review  ·  2 comments  ·  Bugs  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating