FORMAT returns large row size and data sizeWould using varchar(5000) be bad compared to varchar(255)?Difference in Size of SQL Server 2008 R2 backup on Local disk and on Remote Network ShareMoving data from table with VARCHAR(50) fields to table with numeric fields increases table sizeEstimated row size and estimated data size is incorrectEffect of changing data types with row compression enabledActual Number of rows is too high even with new tablescomparing left join and outer apply doing the same thingDespite STATISTICS is updated, Estimated and Actual Row count is not sameShredding Query Plan XML For Potential Skewed Estimates - Data Type ConversionsStatistics and row estimationWhat are the current best practices concerning varchar sizing in SQL Server?

Can anyone find an image of Henry Bolingbroke's Sovereygne Feather Seal?

Travel to USA with a stuffed puppet

Is there any reason to change the ISO manually?

What would a biological creature need in order to see into the future?

What's the point of this macro?

Tiny image scraper for xkcd.com

Tying double knot of garbarge bag

Is a paralyzed creature limp or rigid?

What's the eccentricity of an orbit (trajectory) falling straight down towards the center?

Why would a hard-tail guitar need a locking nut?

What are some countries where you can be imprisoned for reading or owning a Bible?

Are there mathematical concepts that exist in the fourth dimension, but not in the third dimension?

What drugs were used in England during the High Middle Ages?

What quests do you need to stop at before you make an enemy of a faction for each faction?

What is the statistical difference between "choose either total" or "choose new total" when rerolling damage die?

Was "The Hobbit" ever abridged?

Zermelo's proof for unique factorisation

Why is a pressure canner needed when canning?

What is the majority of the UK Government as of 2019-09-04?

Do resonant antennas actually resonate?

Is there any difference between these two sentences? (Adverbs)

Draw the ☣ (Biohazard Symbol)

Is it possible to observe space debris with Binoculars?

Where on Earth is it easiest to survive in the wilderness?



FORMAT returns large row size and data size


Would using varchar(5000) be bad compared to varchar(255)?Difference in Size of SQL Server 2008 R2 backup on Local disk and on Remote Network ShareMoving data from table with VARCHAR(50) fields to table with numeric fields increases table sizeEstimated row size and estimated data size is incorrectEffect of changing data types with row compression enabledActual Number of rows is too high even with new tablescomparing left join and outer apply doing the same thingDespite STATISTICS is updated, Estimated and Actual Row count is not sameShredding Query Plan XML For Potential Skewed Estimates - Data Type ConversionsStatistics and row estimationWhat are the current best practices concerning varchar sizing in SQL Server?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








3















I am surprise with one of my findings that using a FORMAT () does have very big impact on the row size and data size. It is almost 250x more of the size of not applying FORMAT ().



My question is:

1) Why does using FORMAT() have such big impact on the size? To me, is just 1.23 vs $1.23 difference, which is probably 1 character difference. And does it matter with such huge size?



2) Why do we still be encouraged to use FORMAT() in SQL server instead of using string concatenation as below. Since below is only 2X data size, and using format returns 250x data size. OR is that data size is not a critical measurement?



SELECT '$' + CONVERT(varchar(10), UnitPrice) FROM Sales.SalesOrderDetail;


3) Does having data size of 464MB means i will be returning 464MB of data to client?



========================================================



Below is my findings with AdventureWorks2012 database.



SELECT UnitPrice FROM Sales.SalesOrderDetail;


Actual Number of Rows: 121317

Estimated Number of Rows: 121317

Estimated Row Size: 15B

Estimated Data Size: 1777KB



SELECT '$' + CONVERT(varchar (10), UnitPrice) FROM Sales.SalesOrderDetail;


Actual Number of Rows: 121317

Estimated Row Size: 26B

Estimated Data Size: 3060KB



SELECT FORMAT(UnitPrice, 'c') FROM Sales.SalesOrderDetail;


Actual Number of Rows: 121317

Estimated Row Size: 4011B

Estimated Data Size: 464MB










share|improve this question









New contributor



c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



























    3















    I am surprise with one of my findings that using a FORMAT () does have very big impact on the row size and data size. It is almost 250x more of the size of not applying FORMAT ().



    My question is:

    1) Why does using FORMAT() have such big impact on the size? To me, is just 1.23 vs $1.23 difference, which is probably 1 character difference. And does it matter with such huge size?



    2) Why do we still be encouraged to use FORMAT() in SQL server instead of using string concatenation as below. Since below is only 2X data size, and using format returns 250x data size. OR is that data size is not a critical measurement?



    SELECT '$' + CONVERT(varchar(10), UnitPrice) FROM Sales.SalesOrderDetail;


    3) Does having data size of 464MB means i will be returning 464MB of data to client?



    ========================================================



    Below is my findings with AdventureWorks2012 database.



    SELECT UnitPrice FROM Sales.SalesOrderDetail;


    Actual Number of Rows: 121317

    Estimated Number of Rows: 121317

    Estimated Row Size: 15B

    Estimated Data Size: 1777KB



    SELECT '$' + CONVERT(varchar (10), UnitPrice) FROM Sales.SalesOrderDetail;


    Actual Number of Rows: 121317

    Estimated Row Size: 26B

    Estimated Data Size: 3060KB



    SELECT FORMAT(UnitPrice, 'c') FROM Sales.SalesOrderDetail;


    Actual Number of Rows: 121317

    Estimated Row Size: 4011B

    Estimated Data Size: 464MB










    share|improve this question









    New contributor



    c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.























      3












      3








      3








      I am surprise with one of my findings that using a FORMAT () does have very big impact on the row size and data size. It is almost 250x more of the size of not applying FORMAT ().



      My question is:

      1) Why does using FORMAT() have such big impact on the size? To me, is just 1.23 vs $1.23 difference, which is probably 1 character difference. And does it matter with such huge size?



      2) Why do we still be encouraged to use FORMAT() in SQL server instead of using string concatenation as below. Since below is only 2X data size, and using format returns 250x data size. OR is that data size is not a critical measurement?



      SELECT '$' + CONVERT(varchar(10), UnitPrice) FROM Sales.SalesOrderDetail;


      3) Does having data size of 464MB means i will be returning 464MB of data to client?



      ========================================================



      Below is my findings with AdventureWorks2012 database.



      SELECT UnitPrice FROM Sales.SalesOrderDetail;


      Actual Number of Rows: 121317

      Estimated Number of Rows: 121317

      Estimated Row Size: 15B

      Estimated Data Size: 1777KB



      SELECT '$' + CONVERT(varchar (10), UnitPrice) FROM Sales.SalesOrderDetail;


      Actual Number of Rows: 121317

      Estimated Row Size: 26B

      Estimated Data Size: 3060KB



      SELECT FORMAT(UnitPrice, 'c') FROM Sales.SalesOrderDetail;


      Actual Number of Rows: 121317

      Estimated Row Size: 4011B

      Estimated Data Size: 464MB










      share|improve this question









      New contributor



      c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      I am surprise with one of my findings that using a FORMAT () does have very big impact on the row size and data size. It is almost 250x more of the size of not applying FORMAT ().



      My question is:

      1) Why does using FORMAT() have such big impact on the size? To me, is just 1.23 vs $1.23 difference, which is probably 1 character difference. And does it matter with such huge size?



      2) Why do we still be encouraged to use FORMAT() in SQL server instead of using string concatenation as below. Since below is only 2X data size, and using format returns 250x data size. OR is that data size is not a critical measurement?



      SELECT '$' + CONVERT(varchar(10), UnitPrice) FROM Sales.SalesOrderDetail;


      3) Does having data size of 464MB means i will be returning 464MB of data to client?



      ========================================================



      Below is my findings with AdventureWorks2012 database.



      SELECT UnitPrice FROM Sales.SalesOrderDetail;


      Actual Number of Rows: 121317

      Estimated Number of Rows: 121317

      Estimated Row Size: 15B

      Estimated Data Size: 1777KB



      SELECT '$' + CONVERT(varchar (10), UnitPrice) FROM Sales.SalesOrderDetail;


      Actual Number of Rows: 121317

      Estimated Row Size: 26B

      Estimated Data Size: 3060KB



      SELECT FORMAT(UnitPrice, 'c') FROM Sales.SalesOrderDetail;


      Actual Number of Rows: 121317

      Estimated Row Size: 4011B

      Estimated Data Size: 464MB







      sql-server sql-server-2012






      share|improve this question









      New contributor



      c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.










      share|improve this question









      New contributor



      c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      share|improve this question




      share|improve this question








      edited 7 hours ago









      Shekar Kola

      5521 silver badge13 bronze badges




      5521 silver badge13 bronze badges






      New contributor



      c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      asked 8 hours ago









      c448548c448548

      355 bronze badges




      355 bronze badges




      New contributor



      c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




      New contributor




      c448548 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.

























          1 Answer
          1






          active

          oldest

          votes


















          5
















          FORMAT() has an (admittedly undocumented) output of nvarchar(4000), at least in the cases of converting ints and dates to strings. The documentation simply says...




          The length of the return value is determined by the format.




          But then doesn't explain or provide any examples. You can see what I'm describing, though, with:



          SELECT TOP (1) object_id, x = FORMAT(object_id, 'en-us') 
          INTO #blat FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#blat';


          Result is that x is an nvarchar with a length of 8,000 (this is the number of bytes, not the number of characters).



          Estimated row size is based on an assumption that variable width values will be half-populated. So, it expects 2,000 characters (4,000 bytes) on each row (even if the particular parameters you supply can't possibly result in that many characters). I demonstrate this (but not with FORMAT() specifically) in another answer, Would using varchar(5000) be bad compared to varchar(255)?



          This is one reason I prefer to use CONVERT() and TRY_CONVERT() equivalents instead of FORMAT(), in spite of its syntactic sugar. At least with those you can convert to a defined width instead of relying on it "being determined by the format." Which may or may help estimated size, depending on the query. Another example that demonstrates the benefit here (even though it requires uglier code):



          DECLARE @m float = 32.74532323;

          SELECT
          a = @m,
          b = FORMAT(@m, 'c'),
          c = '$' + CONVERT(varchar(12), CONVERT(decimal(8,2),@m))
          INTO #splunge
          FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#splunge';


          Results:



          a float
          b nvarchar(4000)
          c varchar(13)


          Another reason I prefer to use CONVERT() and TRY_CONVERT() is that FORMAT() sucks from a performance perspective (see FORMAT() is nice and all, but…).



          Also please don't ever use variable-width types like varchar without also specifying a length.






          share|improve this answer



























          • Can i conclude that the estimated data size is irrelavent to the results data size return to client. The results data size return to client will be the actual size depending on the number of characters return. Meaning that my client would receive same result size for using FORMAT() and with using CONVERT() as long as both produce similar output.

            – c448548
            8 hours ago







          • 1





            @c448548 Yes, I think I showed exactly that. SQL Server doesn't actually measure the output because it has to make a guess at memory requirements before it actually sees any of the data. Could it be smarter about this? Sure. But it's not today.

            – Aaron Bertrand
            7 hours ago














          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "182"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );






          c448548 is a new contributor. Be nice, and check out our Code of Conduct.









          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f246975%2fformat-returns-large-row-size-and-data-size%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          5
















          FORMAT() has an (admittedly undocumented) output of nvarchar(4000), at least in the cases of converting ints and dates to strings. The documentation simply says...




          The length of the return value is determined by the format.




          But then doesn't explain or provide any examples. You can see what I'm describing, though, with:



          SELECT TOP (1) object_id, x = FORMAT(object_id, 'en-us') 
          INTO #blat FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#blat';


          Result is that x is an nvarchar with a length of 8,000 (this is the number of bytes, not the number of characters).



          Estimated row size is based on an assumption that variable width values will be half-populated. So, it expects 2,000 characters (4,000 bytes) on each row (even if the particular parameters you supply can't possibly result in that many characters). I demonstrate this (but not with FORMAT() specifically) in another answer, Would using varchar(5000) be bad compared to varchar(255)?



          This is one reason I prefer to use CONVERT() and TRY_CONVERT() equivalents instead of FORMAT(), in spite of its syntactic sugar. At least with those you can convert to a defined width instead of relying on it "being determined by the format." Which may or may help estimated size, depending on the query. Another example that demonstrates the benefit here (even though it requires uglier code):



          DECLARE @m float = 32.74532323;

          SELECT
          a = @m,
          b = FORMAT(@m, 'c'),
          c = '$' + CONVERT(varchar(12), CONVERT(decimal(8,2),@m))
          INTO #splunge
          FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#splunge';


          Results:



          a float
          b nvarchar(4000)
          c varchar(13)


          Another reason I prefer to use CONVERT() and TRY_CONVERT() is that FORMAT() sucks from a performance perspective (see FORMAT() is nice and all, but…).



          Also please don't ever use variable-width types like varchar without also specifying a length.






          share|improve this answer



























          • Can i conclude that the estimated data size is irrelavent to the results data size return to client. The results data size return to client will be the actual size depending on the number of characters return. Meaning that my client would receive same result size for using FORMAT() and with using CONVERT() as long as both produce similar output.

            – c448548
            8 hours ago







          • 1





            @c448548 Yes, I think I showed exactly that. SQL Server doesn't actually measure the output because it has to make a guess at memory requirements before it actually sees any of the data. Could it be smarter about this? Sure. But it's not today.

            – Aaron Bertrand
            7 hours ago
















          5
















          FORMAT() has an (admittedly undocumented) output of nvarchar(4000), at least in the cases of converting ints and dates to strings. The documentation simply says...




          The length of the return value is determined by the format.




          But then doesn't explain or provide any examples. You can see what I'm describing, though, with:



          SELECT TOP (1) object_id, x = FORMAT(object_id, 'en-us') 
          INTO #blat FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#blat';


          Result is that x is an nvarchar with a length of 8,000 (this is the number of bytes, not the number of characters).



          Estimated row size is based on an assumption that variable width values will be half-populated. So, it expects 2,000 characters (4,000 bytes) on each row (even if the particular parameters you supply can't possibly result in that many characters). I demonstrate this (but not with FORMAT() specifically) in another answer, Would using varchar(5000) be bad compared to varchar(255)?



          This is one reason I prefer to use CONVERT() and TRY_CONVERT() equivalents instead of FORMAT(), in spite of its syntactic sugar. At least with those you can convert to a defined width instead of relying on it "being determined by the format." Which may or may help estimated size, depending on the query. Another example that demonstrates the benefit here (even though it requires uglier code):



          DECLARE @m float = 32.74532323;

          SELECT
          a = @m,
          b = FORMAT(@m, 'c'),
          c = '$' + CONVERT(varchar(12), CONVERT(decimal(8,2),@m))
          INTO #splunge
          FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#splunge';


          Results:



          a float
          b nvarchar(4000)
          c varchar(13)


          Another reason I prefer to use CONVERT() and TRY_CONVERT() is that FORMAT() sucks from a performance perspective (see FORMAT() is nice and all, but…).



          Also please don't ever use variable-width types like varchar without also specifying a length.






          share|improve this answer



























          • Can i conclude that the estimated data size is irrelavent to the results data size return to client. The results data size return to client will be the actual size depending on the number of characters return. Meaning that my client would receive same result size for using FORMAT() and with using CONVERT() as long as both produce similar output.

            – c448548
            8 hours ago







          • 1





            @c448548 Yes, I think I showed exactly that. SQL Server doesn't actually measure the output because it has to make a guess at memory requirements before it actually sees any of the data. Could it be smarter about this? Sure. But it's not today.

            – Aaron Bertrand
            7 hours ago














          5














          5










          5









          FORMAT() has an (admittedly undocumented) output of nvarchar(4000), at least in the cases of converting ints and dates to strings. The documentation simply says...




          The length of the return value is determined by the format.




          But then doesn't explain or provide any examples. You can see what I'm describing, though, with:



          SELECT TOP (1) object_id, x = FORMAT(object_id, 'en-us') 
          INTO #blat FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#blat';


          Result is that x is an nvarchar with a length of 8,000 (this is the number of bytes, not the number of characters).



          Estimated row size is based on an assumption that variable width values will be half-populated. So, it expects 2,000 characters (4,000 bytes) on each row (even if the particular parameters you supply can't possibly result in that many characters). I demonstrate this (but not with FORMAT() specifically) in another answer, Would using varchar(5000) be bad compared to varchar(255)?



          This is one reason I prefer to use CONVERT() and TRY_CONVERT() equivalents instead of FORMAT(), in spite of its syntactic sugar. At least with those you can convert to a defined width instead of relying on it "being determined by the format." Which may or may help estimated size, depending on the query. Another example that demonstrates the benefit here (even though it requires uglier code):



          DECLARE @m float = 32.74532323;

          SELECT
          a = @m,
          b = FORMAT(@m, 'c'),
          c = '$' + CONVERT(varchar(12), CONVERT(decimal(8,2),@m))
          INTO #splunge
          FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#splunge';


          Results:



          a float
          b nvarchar(4000)
          c varchar(13)


          Another reason I prefer to use CONVERT() and TRY_CONVERT() is that FORMAT() sucks from a performance perspective (see FORMAT() is nice and all, but…).



          Also please don't ever use variable-width types like varchar without also specifying a length.






          share|improve this answer















          FORMAT() has an (admittedly undocumented) output of nvarchar(4000), at least in the cases of converting ints and dates to strings. The documentation simply says...




          The length of the return value is determined by the format.




          But then doesn't explain or provide any examples. You can see what I'm describing, though, with:



          SELECT TOP (1) object_id, x = FORMAT(object_id, 'en-us') 
          INTO #blat FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#blat';


          Result is that x is an nvarchar with a length of 8,000 (this is the number of bytes, not the number of characters).



          Estimated row size is based on an assumption that variable width values will be half-populated. So, it expects 2,000 characters (4,000 bytes) on each row (even if the particular parameters you supply can't possibly result in that many characters). I demonstrate this (but not with FORMAT() specifically) in another answer, Would using varchar(5000) be bad compared to varchar(255)?



          This is one reason I prefer to use CONVERT() and TRY_CONVERT() equivalents instead of FORMAT(), in spite of its syntactic sugar. At least with those you can convert to a defined width instead of relying on it "being determined by the format." Which may or may help estimated size, depending on the query. Another example that demonstrates the benefit here (even though it requires uglier code):



          DECLARE @m float = 32.74532323;

          SELECT
          a = @m,
          b = FORMAT(@m, 'c'),
          c = '$' + CONVERT(varchar(12), CONVERT(decimal(8,2),@m))
          INTO #splunge
          FROM sys.all_objects;

          EXEC tempdb.sys.sp_help N'#splunge';


          Results:



          a float
          b nvarchar(4000)
          c varchar(13)


          Another reason I prefer to use CONVERT() and TRY_CONVERT() is that FORMAT() sucks from a performance perspective (see FORMAT() is nice and all, but…).



          Also please don't ever use variable-width types like varchar without also specifying a length.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 6 hours ago









          Erik Darling

          27.1k13 gold badges83 silver badges137 bronze badges




          27.1k13 gold badges83 silver badges137 bronze badges










          answered 8 hours ago









          Aaron BertrandAaron Bertrand

          160k19 gold badges320 silver badges526 bronze badges




          160k19 gold badges320 silver badges526 bronze badges















          • Can i conclude that the estimated data size is irrelavent to the results data size return to client. The results data size return to client will be the actual size depending on the number of characters return. Meaning that my client would receive same result size for using FORMAT() and with using CONVERT() as long as both produce similar output.

            – c448548
            8 hours ago







          • 1





            @c448548 Yes, I think I showed exactly that. SQL Server doesn't actually measure the output because it has to make a guess at memory requirements before it actually sees any of the data. Could it be smarter about this? Sure. But it's not today.

            – Aaron Bertrand
            7 hours ago


















          • Can i conclude that the estimated data size is irrelavent to the results data size return to client. The results data size return to client will be the actual size depending on the number of characters return. Meaning that my client would receive same result size for using FORMAT() and with using CONVERT() as long as both produce similar output.

            – c448548
            8 hours ago







          • 1





            @c448548 Yes, I think I showed exactly that. SQL Server doesn't actually measure the output because it has to make a guess at memory requirements before it actually sees any of the data. Could it be smarter about this? Sure. But it's not today.

            – Aaron Bertrand
            7 hours ago

















          Can i conclude that the estimated data size is irrelavent to the results data size return to client. The results data size return to client will be the actual size depending on the number of characters return. Meaning that my client would receive same result size for using FORMAT() and with using CONVERT() as long as both produce similar output.

          – c448548
          8 hours ago






          Can i conclude that the estimated data size is irrelavent to the results data size return to client. The results data size return to client will be the actual size depending on the number of characters return. Meaning that my client would receive same result size for using FORMAT() and with using CONVERT() as long as both produce similar output.

          – c448548
          8 hours ago





          1




          1





          @c448548 Yes, I think I showed exactly that. SQL Server doesn't actually measure the output because it has to make a guess at memory requirements before it actually sees any of the data. Could it be smarter about this? Sure. But it's not today.

          – Aaron Bertrand
          7 hours ago






          @c448548 Yes, I think I showed exactly that. SQL Server doesn't actually measure the output because it has to make a guess at memory requirements before it actually sees any of the data. Could it be smarter about this? Sure. But it's not today.

          – Aaron Bertrand
          7 hours ago











          c448548 is a new contributor. Be nice, and check out our Code of Conduct.









          draft saved

          draft discarded


















          c448548 is a new contributor. Be nice, and check out our Code of Conduct.












          c448548 is a new contributor. Be nice, and check out our Code of Conduct.











          c448548 is a new contributor. Be nice, and check out our Code of Conduct.














          Thanks for contributing an answer to Database Administrators Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f246975%2fformat-returns-large-row-size-and-data-size%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

          Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

          Ласкавець круглолистий Зміст Опис | Поширення | Галерея | Примітки | Посилання | Навігаційне меню58171138361-22960890446Bupleurum rotundifoliumEuro+Med PlantbasePlants of the World Online — Kew ScienceGermplasm Resources Information Network (GRIN)Ласкавецькн. VI : Літери Ком — Левиправивши або дописавши її