Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
14.11.2019 23:19, Clyde Eisenbeis cte...@gmail.com [firebird-support] wrote: > The previous comments indicate that Firebird is Litle Endian. It doesn't matter because Firebird client deliver length of VARCHAR in native endiannes and for the rest there are API functions to convert implementation-defined byte order into/from native one. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
For a minor clarification. In the electronics world, we specify the sequence of multiple bytes with the word "Endian". Assume the hex number is 0x1A2B. For Big Endian, the 0x1A is first. For Little Endian, the 0x2B is first. The previous comments indicate that Firebird is Litle Endian. (For serial communication we also specify the bit order, LSB or MSB, which is transparent to most folks). On Thu, Nov 14, 2019 at 2:39 PM Dimitry Sibiryakov s...@ibphoenix.com [firebird-support] wrote: > 14.11.2019 20:29, Mark Rotteveel m...@lawinegevaar.nl [firebird-support] > wrote: > > And that part of the documentation is unfortunately wrong (although I'm > > not sure why the language reference even cares to describe such an > > implementation detail). > >This documentation is actively corrected and it is better to read > latest versions > directly from source: > > https://github.com/sim1984/langref25 > https://github.com/sim1984/langref30 > >Google Translate at least won't add anything strange from the blue sky. > > -- >WBR, SD. > > > > > > > ++ > > Visit http://www.firebirdsql.org and click the Documentation item > on the main (top) menu. Try FAQ and other links from the left-side menu > there. > > Also search the knowledgebases at > http://www.ibphoenix.com/resources/documents/ > > ++ > > > Yahoo Groups Links > > > >
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
14.11.2019 20:29, Mark Rotteveel m...@lawinegevaar.nl [firebird-support] wrote: > And that part of the documentation is unfortunately wrong (although I'm > not sure why the language reference even cares to describe such an > implementation detail). This documentation is actively corrected and it is better to read latest versions directly from source: https://github.com/sim1984/langref25 https://github.com/sim1984/langref30 Google Translate at least won't add anything strange from the blue sky. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
14.11.2019 20:29, Mark Rotteveel m...@lawinegevaar.nl [firebird-support] wrote: > Actually Dimitry, Steve was quoting from the Firebird 2.5 Language > Reference: > https://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-datatypes.html#fblangref25-dtyp-tbl-dtypinfo I see. This mostly a translation problem. Original documentation says only "string is right-padded with spaces to given length on display" and nothing about storage or network transfer. Though "on display" here is also a strange expression. I'll point to it to he author if he isn't reading this. > That table contains some more problems, for example for VARCHAR it says > the length is in "two trailing bytes". It is also a translator's liberty. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
On 14-11-2019 19:02, Dimitry Sibiryakov s...@ibphoenix.com [firebird-support] wrote: > 14.11.2019 18:01, blackfalconsoftw...@outlook.com [firebird-support] wrote: >> However, the PDF language manual I have for version 2.5 does in fact state >> the following... >> >> >> "A fixed-length character data type. When its data is displayed, trailing >> spaces are added >> to the string up to the specified length. Trailing spaces are not stored in >> the database >> but are restored to match the defined >> length when the column is displayed on the client side. Network traffic is >> reduced by not >> sending spaces over the LAN. If the number of characters is not specified, 1 >> is used by >> default." > > No, it something completely different from what is written in Language > Reference and it > is plain wrong. Actually Dimitry, Steve was quoting from the Firebird 2.5 Language Reference: https://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-datatypes.html#fblangref25-dtyp-tbl-dtypinfo And that part of the documentation is unfortunately wrong (although I'm not sure why the language reference even cares to describe such an implementation detail). That table contains some more problems, for example for VARCHAR it says the length is in "two trailing bytes". Mark -- Mark Rotteveel
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
On 14-11-2019 18:01, blackfalconsoftw...@outlook.com [firebird-support] wrote: > I found what we have been arguing over in the Firebird 2.5 Language > Reference Manual since I don't seem to have the one for version 3.0. I > looked for it at the Firebird site but it does not appear to be listed... That is because there is no English version for 3.0 yet, unfortunately. > However, the PDF language manual I have for version 2.5 does in fact > state the following... > > "A fixed-length character data type. When its data is displayed, > trailing spaces are added to the string up to the specified length. > Trailing spaces are not stored in the database but are restored to match > the defined > length when the column is displayed on the client side. Network traffic > is reduced by not sending spaces over the LAN. If the number of > characters is not specified, 1 is used by default." Well, that quote is unfortunately wrong. Documentation is written by humans, and humans are fallible. This is probably an incorrect (re)interpretation of what the InterBase 6 Data Definition guide (page 74) says: """ *Trailing blanks* InterBase compresses trailing blanks when it stores fixed-length strings, so data with trailing blanks uses the same amount of space as an equivalent variable-length string. When the data is read, InterBase reinserts the blanks. This saves disk space when the length of the data items varies widely. """ Which seems to be an oversimplification of the RLE compression that is applied on the record when storing (and the fact VARCHAR is actually not much different from CHAR inside the Firebird engine). However for the observable effects for the user there is no difference. > If the CHAR data type is not being stored with the additional padded > characters but only done so in memory as Ann Harrison has stated than I > have so far only found this information to be at odds with other > information I have found regarding this data type. Ann did not say it is only padded in memory. She said "In memory, yes. But the entire record will be compressed before being written to disk.", meaning that on disk, a record can be shorter because of the RLE compression that is applied. However even in that shorter form, the value is still padded (but that padding will be compressed due to the RLE). > Now what is being said is that internally, a CHAR data type no longer > pads its field to the defined length at the point of creation. In this > case then, the field would then always be expanded to the length > required of updated data to the maximum defined at field definition > time. VARCHAR data on the other hand will act in the same manner except > to use its length-info bytes to base its updated storage field size on. No, that is not how it works. See also my other email that described the on-disk encoding form. > So when did this change? Is this a new difference between Firebird 2.5 > and 3.x.x? It did not change, it has been the same since before Firebird 1. You are inferring too much on a minor error in user documentation. > Here is a link to a detailed description as to how the major databases You forgot to post a link. > store CHAR and VARCHAR data internally. With the exception of SQL > Server, which specifies that ANSI_PADDING has to be set to "ON" to store > padded spaces with CHAR data types (which, to my knowledge, is how I > mostly worked with this database engine), all of the listed database > engines (with the exception of SQLite) say about the same thing for such > storage as I have been stating here. For SQLite, this would be expected > of since it is a not a strongly typed database engine. Your description of how SQL Server ANSI_PADDING works is not entirely correct. See https://docs.microsoft.com/en-us/sql/t-sql/statements/set-ansi-padding-transact-sql?view=sql-server-ver15 Specifically look at the table under Remarks and compare the effects for CHAR(n) NOT NULL vs CHAR(n) NULL. With ANSI_PADDING OFF, CHAR(n) NULL behaves as a VARCHAR(n) in SQL Server, while CHAR(n) NOT NULL behaves as a SQL standard CHAR(n). With ANSI_PADDING ON, CHAR(n) NULL behaves as CHAR(n) NOT NULL and as SQL standard CHAR(n). Similarly VARCHAR(n) in SQL Server will trim all spaces in OFF, but preserve significant whitespace (that is explicitly added spaces) when ON. But here also, the behaviour is described from the user-visible effects, and does not necessarily imply anything about the underlying storage implementation. > If in fact there was a significant change to how the Firebird engine > stores such CHAR than it would be mirroring with SQLite and not the > other major database engines available. The behaviour of CHAR and VARCHAR in Firebird are compliant with the SQL standard, the underlying storage implementation does not matter much when you **use** a database, it is about the effective behaviour. However, if you want to discuss internals, then
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
14.11.2019 18:01, blackfalconsoftw...@outlook.com [firebird-support] wrote: > However, the PDF language manual I have for version 2.5 does in fact state > the following... > > > "A fixed-length character data type. When its data is displayed, trailing > spaces are added > to the string up to the specified length. Trailing spaces are not stored in > the database > but are restored to match the defined > length when the column is displayed on the client side. Network traffic is > reduced by not > sending spaces over the LAN. If the number of characters is not specified, 1 > is used by > default." No, it something completely different from what is written in Language Reference and it is plain wrong. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
I found what we have been arguing over in the Firebird 2.5 Language Reference Manual since I don't seem to have the one for version 3.0. I looked for it at the Firebird site but it does not appear to be listed... >>> CHAR DATA TYPE (CHAR(n), CHARACTER(n)) --- CHAR is a fixed-length data type. If the entered number of characters is less than the declared length, trailing spaces will be added to the field. Generally, the pad character does not have to be a space: it depends on the character set, For example, the pad character for the OCTETS character set is zero. The full name of this data type is CHARACTER, but there is no requirement to use full names and people rarely do so. Fixed-length character data can be used to store codes whose length is standard and has a definite “width” in directories. An example of such a code is an EAN13 barcode—13 characters, all filled. However, the PDF language manual I have for version 2.5 does in fact state the following... "A fixed-length character data type. When its data is displayed, trailing spaces are added to the string up to the specified length. Trailing spaces are not stored in the database but are restored to match the defined length when the column is displayed on the client side. Network traffic is reduced by not sending spaces over the LAN. If the number of characters is not specified, 1 is used by default." But the above statement puts such descriptions at odds with each other based upon where one looks for such information. VARCHAR DATA TYPE (VARCHAR(n), CHAR VARYING, CHARACTER VARYING) --- VARCHAR is the basic string type for storing texts of variable length, up to a maximum of 32,765 bytes. The stored structure is equal to the actual size of the data plus 2 bytes where the length of the data is recorded. All characters that are sent from the client application to the database are considered meaningful, including the leading and trailing spaces. However, trailing spaces are not stored: they will be restored upon retrieval, up to the recorded length of the string. The full name of this type is CHARACTER VARYING. Another variant of the name is written as CHAR VARYING. <<< This is the information I have been going by in addition to the link that sent me to the IB-Experts web page of the same. If the CHAR data type is not being stored with the additional padded characters but only done so in memory as Ann Harrison has stated than I have so far only found this information to be at odds with other information I have found regarding this data type. Now what is being said is that internally, a CHAR data type no longer pads its field to the defined length at the point of creation. In this case then, the field would then always be expanded to the length required of updated data to the maximum defined at field definition time. VARCHAR data on the other hand will act in the same manner except to use its length-info bytes to base its updated storage field size on. So when did this change? Is this a new difference between Firebird 2.5 and 3.x.x? Here is a link to a detailed description as to how the major databases store CHAR and VARCHAR data internally. With the exception of SQL Server, which specifies that ANSI_PADDING has to be set to "ON" to store padded spaces with CHAR data types (which, to my knowledge, is how I mostly worked with this database engine), all of the listed database engines (with the exception of SQLite) say about the same thing for such storage as I have been stating here. For SQLite, this would be expected of since it is a not a strongly typed database engine. If in fact there was a significant change to how the Firebird engine stores such CHAR than it would be mirroring with SQLite and not the other major database engines available. I have worked with MS SQL Server, Oracle, Sybase, MySQL, PostgreSQL (Ingress), and SQLite. However, I did not like using the latter engine and is why I have chosen Firebird for all my current development efforts. Steve Naidamast Sr. Software Engineer
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
On 2019-11-13 17:37, blackfalconsoftw...@outlook.com [firebird-support] wrote: > Your statement, which may be true, does not sit well with a previous > statement that states that a VARCHAR field of 1000 characters is > stored in the table with 1000 characters. > > Your statement is suggesting a null length (until the field is > updated) with two bytes for an actual length, which is how VARCHAR > fields work in all other databases to my knowledge. Otherwise, to > follow the previous statement, a Firebird table could have a VARCHAR > field for 1000 characters, be stored as such with the initial > storage-info bytes holding the actual length, which would be 1000. > When the field is updated to lets say 20 characters of data, the field > would still have an actual size of 1000 characters but the > storage-info would be 20. > > How does this make any sense? A record on-disk is a compressed version of the in-memory image of the data of a row. A VARCHAR(1000) in server memory has 2 bytes for the actual data and 1000 bytes for the data, and 2 bytes padding to make it a multiple of 4. Bytes beyond the actual data length are zeroed-out. When written to disk, a RLE compression is applied, so a VARCHAR(1000) containing 'A' will be something like (in hexadecimal): 03 01 00 41 80 00 80 00 80 00 80 00 80 00 80 00 80 00 97 00 Where 03 means: next 3 bytes literally 01 00 means: actual length 1 41 means: literally A 80 00 means: repeat 128 times 00 (x7) 97 00 means: repeat 105 times 00 These last two give a total of 1001 0x00 bytes (zero-padded value + additional padding to make it a multiple of 4. A CHAR(1000) with value A would be encoded as: 01 41 80 20 80 20 80 20 80 20 80 20 80 20 80 20 99 20 Where: 01 menas: next 1 bytes literally 41 means: literally A 80 20 means: repeat 128 times 20 (space) (x7) 99 20 means: repeat 103 times 20 (space) These last two give a total of 999 0x20 bytes (space-padded value), no additional padding because value is already a multiple of 4. NOTE: I might have some details wrong, but this is how it basically work. The Firebird Internal docoument, section data page also describes this: https://firebirdsql.org/file/documentation/reference_manuals/reference_material/html/fbint-page-5.html Mark
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
14.11.2019 17:08, blackfalconsoftw...@outlook.com [firebird-support] wrote: > The links provided to me had the information on the IB-Experts web site... I didn't see who provided you any link, but here is right one: https://firebirdsql.org/en/reference-manuals/ At the bottom of this page you can see "InterBase 6.0 Manuals". Those which you need are "API Guide", "Data Definition Guide" and at some extent "Embedded SQL Guide". -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
The links provided to me had the information on the IB-Experts web site... If there information is incorrect, you should contact them to have it corrected... Steve Naidamast Sr. Software Engineer
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
On 2019-11-13 18:42, blackfalconsoftw...@outlook.com [firebird-support] wrote: > Here is the link to the definition of CHAR and VARCHAR field > definitions from the IB-Experts site... > > > https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR > https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR > In neither the CHAR or VARCHAR definitions is it noted that unused > space is filled with nulls or blank data as both are stored as > variable length fields internally within a table. That is incorrect. A CHAR will be stored blank-padded (space for normal character sets, 0x00 for octets), while a VARCHAR will be stored 0x00 padded. However, due to a RLE (Run Lenght Encoding) applied, that padded will be stored 'compressed'. > However, the CHAR > data type, as would be expected, can only store as a maximum, the > number of characters that its original definition set forth. The > VARCHAR field can hold up to over 32,000+ bytes of data. That is incorrect. Both a VARCHAR(n) and a CHAR(n) will allow storing a maximum of n characters, the only difference is that the value (as seen by the consumer) of a CHAR(n) is right-padded with spaces, while a VARCHAR(n) is not padded. Mark
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
13.11.2019 18:42, blackfalconsoftw...@outlook.com [firebird-support] wrote: > So my understanding of how the VARCHAR field works is correct and what I have > stated earlier. Your understanding is wrong and either IB Expert site is wrong as well or you misread it. Yest remember: CHAR - for fixed length data, VARCHAR - for variable length data. That's all. The rest is irrelevant for your job. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
[firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
Here is the link to the definition of CHAR and VARCHAR field definitions from the IB-Experts site... https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR https://www.ibexpert.net/ibe/index.php?n=Doc.CHAR It defines the storing of CHAR and VARCHAR in the same manner, though the VARCHAR data type is provided the extra two bytes for actual length information. In neither the CHAR or VARCHAR definitions is it noted that unused space is filled with nulls or blank data as both are stored as variable length fields internally within a table. However, the CHAR data type, as would be expected, can only store as a maximum, the number of characters that its original definition set forth. The VARCHAR field can hold up to over 32,000+ bytes of data. Thus Firebird, does in fact store VARCHAR data within its tables as all other database engines do, Its only deviation is that the CHAR field definition is made variable, similar to a VARCHAR field but only up to the maximum length initially defined. So my understanding of how the VARCHAR field works is correct and what I have stated earlier. Anne Harrison's comments also mirror what this link provides as when either a CHAR or VARCHAR field is placed in memory than the full lengths of each field definition type is provided space for. The reading suggestions you recommended are what provided the link above to the IB-Experts site... Steve Naidamast Sr. Software Engineer
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
13.11.2019 17:37, blackfalconsoftw...@outlook.com [firebird-support] wrote: > Your statement is suggesting a null length (until the field is updated) with > two bytes for > an actual length, which is how VARCHAR fields work in all other databases to > my > knowledge. Otherwise, to follow the previous statement, a Firebird table > could have a > VARCHAR field for 1000 characters, be stored as such with the initial > storage-info bytes > holding the actual length, which would be 1000. When the field is updated to > lets say 20 > characters of data, the field would still have an actual size of 1000 > characters but the > storage-info would be 20. > > How does this make any sense? Nothing you said make sense. There nothing like "initial storage-info". I recommend you to read Interbase API Guide and Developers Guide in part of "Data Types" to understand how data types are represented internally. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
[firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
Your statement, which may be true, does not sit well with a previous statement that states that a VARCHAR field of 1000 characters is stored in the table with 1000 characters. Your statement is suggesting a null length (until the field is updated) with two bytes for an actual length, which is how VARCHAR fields work in all other databases to my knowledge. Otherwise, to follow the previous statement, a Firebird table could have a VARCHAR field for 1000 characters, be stored as such with the initial storage-info bytes holding the actual length, which would be 1000. When the field is updated to lets say 20 characters of data, the field would still have an actual size of 1000 characters but the storage-info would be 20. How does this make any sense? Steve Naidamast Sr. Software Engineer
Re: [firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
13.11.2019 16:09, blackfalconsoftw...@outlook.com [firebird-support] wrote: > If a VARCHAR field is defined for 1000 characters and it is stored in the > table at a 1000 > character length than there is no purpose to an actual VARCHAR field > definition. There is. I addition to 1000 characters two bytes of real length is stored. And believe or not it is a huge advantage. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
[firebird-support] Re: What are the trade-offs of CHAR vs. VARCHAR?
Though I cannot dispute what you are saying, to me it does not make much sense. If a VARCHAR field is defined for 1000 characters and it is stored in the table at a 1000 character length than there is no purpose to an actual VARCHAR field definition. VARCHAR fields have always been dynamic in other database engines and what you are saying appears to have Firebird be the only database engine to not support dynamically allocated VARCHAR fields... Steve Naidamast Sr. Software Engineer
