Activity for Paul Baker
-
Paul Baker committed [r858] on Code
Fix H2077 Value assigned never used
-
Fix W1058 Implicit string cast with data loss
-
Fix W1035 Return value might be undefined
-
Fix W1057 Implicit string cast
-
Fix E2003 Undeclared identifier: 'DateSeparator'
-
add CTOD() function to parser
-
add date comparison operators to parser
-
add date literal to parser
-
Support NULL datetime constant
-
add AT() function to parser
-
add DELETED() function to parser
-
This seems to be a missing feature. There is no concept of a boolean constant - see TConstant in dbf_prsdef.pas.
-
This table uses the field type "W", which is not part of the dBASE standard. The trunk of TDbf reports "Invalid file". I don't think we'd want to break the standard, especially without knowing more about what created this file. The best solution is to avoid using dBASE entirely if you are using Unicode.
-
I would recommend working around this, for now, by disregarding the packages and adding the src folder to your search path. There was only one revision since 2006, it's possible it never worked. The published interface is the same as the fork that comes with Lazarus/FPC, so no harm is done using the TDbf component on a form.
-
Thanks! I see that you are using LIBSUFFIX AUTO. Do we want to use it going back to when it was introduced in RAD Studio Sydney 10.4?
-
What instructions are you following? You are opening packages\Delphi101\tdbf101.groupproj in the IDE? I would right-click tdbf240.bpl, then Build, then right-click dcltdbf240.bpl, then Install. It is trying to install tdbf240.bpl, which makes me wonder whether you clicked the wrong one by accident. I had no problem with the Delphi 11 packages. I compared the Delphi11 folder to the Delphi101 folder and saw no significant differences, so that should work too, but I cannot try to reproduce it because...
-
For some reason, I cannot see earlier comments in this discussion, so I don't know where I made the mistake, but I do now see what you are referring to. Does r845 fix it for you?
-
Fix description of Delphi 10.4 Sydney runtime package
-
Fix potential Range Check Error getting/setting field value
-
Can you reproduce this in revision 843? I fixed a memo bug in revision 804.
-
Can you reproduce this in revision 843? I fix a memo bug in revision 804.
-
I simplified your example, demonstrating what I was suggesting - a console application with one file, the DPR. Here's how I'd request that you simplify it further, so that anyone can reproduce it just by pasting this code in any Delphi version and running it. * Add verification code that raises an exception if the problem occurs. * Create the files we need at runtime using TDbf.CreateTable(), if possible, instead of depending on the test.dbf and test.fpt files you provided. It may not be possible...
-
compile for 64 bit delphi
-
Closed due to lack of information.
-
Empty field evaluated as 0 (zero) when parsed as string
-
Close due to lack of information.
-
MDX don't work
-
MDX files work for me, and the relevant code has changed a lot since the issue was created. So, I am closing this.
-
Indexing string with codepage 1250
-
I am closing this, because dBASE does not support your language and TDbf does what it can to correctly follow the dBASE protocol.
-
Fix AV packing table if filter is active
-
Fix compiler error in Delphi version older than 3
-
Check that field size is non-zero
-
Check that native field type is valid
-
Check that field count is non-zero
-
Treat + the same as other level 7 types
-
Do not clear native field type
-
Validate field definitions before creating table
-
It sounds like what you ideally need is a language driver that uses code page 1050. There isn't much dBASE documentation, and what there is is scattered around the Internet, but I think this is the only European languages that does not have a language driver. I don't think dBASE even supports your language 😞 Are you able to use Borland Database Engine for this data? If so, we might be able to emulate that, if we can get a copy of a working database. Is this the same problem as yours? It seems to...
-
It sounds like what you ideally need is a language driver that uses code page 1050. There isn't much dBASE documentation, and what there is is scattered around the Internet, but I think this is the only European languages that does not have a language driver. I don't think dBASE even supports your language 😞 Are you able to use Borland Database Engine for this data? If so, we might be able to emulate that, if we can get a copy of a working database. It would also solve the problem not to translate...
-
Fix W1000 Symbol is deprecated
-
Fix W1057 Implicit string cast
-
Get exclusive access to table to rebuild indexes
-
Consistently use temp buffer created by TDbf
-
Check can modify before attempting delete
-
Fix "Division by zero" error in TDbf Viewer
-
Reset cursor position after PackTable()
-
Fix language ID in index tag header
-
Fix memory leak of menu items
-
Remove unused variable
-
Include file name in status bar
-
Use initial Auto Increment value of 1
-
Allow Auto Increment value to roll over
-
Fix Auto Increment value in TDbf Viewer
-
Fix field values in 64-bit build
-
Fix potential AV setting field in 64-bit build
-
Add Delphi 11 libraries to search path
-
Add Delphi 11 test projects
-
Move test project source to shared include file
-
Add DUnit reference to Delphi 7 projects
-
Move Delphi 7 project files to subfolder
-
Move Delphi 7 project files to subfolder
-
Fix parsing of Numeric (N) BCD index key
-
Fixed compiler error in Delphi 2009 or higher
-
Associate en-US with DBWINUS0 language driver
-
To summarise, I believe you need language driver 0xC8 (aka DB1250CZ0), which is associated with code page 1250 and locale ID 1029 (aka cs-CZ). However, your system has code page 1250 and locale ID 1050 (aka hr-HR), which it fails to match to a language driver. It still needs to be fixed but, as a workaround, does setting DbfGlobals.DefaultCreateLangId := FoxLangId_EEurope_1250; before creating the table give you the expected results? BTW, How to interpret the language driver name in a dBase (.dbf)...
-
To summarise, I believe you need language driver 0xC8 (aka DB1250CZ0), which is associated with code page 1250 and locale ID 1029 (aka cs-CZ). However, your system has code page 1250 and locale ID 1050 (aka hr-HR), which it fails to match to a language driver. It still needs to be fixed but, as a workaround, does setting DbfGlobals.DefaultCreateLangId := FoxLangId_EEurope_1250; before creating the table? BTW, How to interpret the language driver name in a dBase (.dbf) file? mostly agrees with the...
-
To summarise, I believe you need language driver 0xC8 (aka DB1250CZ0), which is associated with code page 1250 and locale ID 1029 (aka cs-CZ). However, your system has code page 1250 and locale ID 1050 (aka hr-HR), which it fails to match to a language driver. BTW, How to interpret the language driver name in a dBase (.dbf) file? mostly agrees with the data in dbf_lang.pas. '01' => 'cp437' # U.S. MS-DOS '02' => 'cp850' # International MS-DOS '03' => 'cp1252' # Windows ANSI '08' => 'cp865' # Danish...
-
To summarise, I believe you need language driver 0xC8 (aka DB1250CZ0), which is associated with code page 1250 and locale ID 1029 (aka cs-CZ). However, your system has code page 1250 and locale ID 1050 (aka hr-HR), which it fails to match to a language driver. I also noticed that on typical US machine, which has code page 1252 and locale ID 1033 (aka. en-US), BDE uses language driver 0x57 (aka DBWINUS0), associated with code page 1252, whereas TDbf uses language driver 0x37 (aka DB850US0), associated...
-
To summarise, I believe you need language driver 0xC8 (aka DB1250CZ0), which is associated with code page 1250 and locale ID 1029 (aka cs-CZ). However, your system has code page 1250 and locale ID 1050 (aka hr-HR), which it fails to match to a language driver. I also noticed that on an en-US machine, BDE uses language driver 0x57 (aka DBWINUS0), associated with code page 1252, whereas TDbf uses language driver 0x37 (aka DB850US0), associated with code page 850. The more I read about language drivers,...
-
To summarise, I believe you need language driver 0xC8 (aka DB1250CZ0), which is associated with code page 1250 and locale ID 1029 (aka cs-CZ). However, your system has code page 1250 and locale ID 1050 (aka hr-HR), which it fails to match to a language driver. I also noticed that on an en-US machine, BDE uses language driver 0x57 (aka DBWINUS0), associated with code page 1252, whereas TDbf uses language driver 0x37 (aka DB850US0), associated with code page 850. The more I read about language drivers,...
-
To summarise, I believe you need language driver 0xC8 (aka DB1250CZ0), which is associated with code page 1250 and locale ID 1029 (aka cs-CZ). However, your system has code page 1250 and locale ID 1050 (aka hr-HR), which it fails to match to a language driver. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file I also noticed that on an en-US machine, BDE uses language driver 0x57 (aka DBWINUS0), associated with code page 1252, whereas TDbf uses...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: BDE uses 0x57 aka DBWINUS0. - This is commented as "Ascii: Binary" and has a locale of 0 in the source code. - Does "WIN" refer to whatever the Windows code page is? - TDbf translates to/from code page 1252! - TDbf does NOT use a collation table when sorting! TDbf uses 0x37 aka...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: BDE uses 0x57 aka DBWINUS0. - This is commented as "Ascii: Binary" and has a locale of 0 in the source code. - Does "WIN" refer to whatever the Windows code page is? - TDbf translates to/from code page 1252! - TDbf does NOT use a collation table when sorting! TDbf uses 0x37 aka...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: BDE uses 0x57 aka DBWINUS0. - This is commented as "Ascii: Binary" and has a locale of 0 in the source code. - Does "WIN" refer to whatever the Windows code page is? - TDbf translates to/from code page 1252! TDbf uses 0x37 aka DB850US0. - This is code page 850 and locale 1033....
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: BDE uses 0x57 aka DBWINUS0. - This is commented as "Ascii: Binary" and has a locale of 0 in the source code. - Does "WIN" refer to whatever the Windows code page is? - TDbf translates to/from code page 1252! TDbf uses 0x37 aka DB850US0. This is code page 850 and locale 1033. -...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: * BDE uses 0x57 aka DBWINUS0. This s commented as "Ascii: Binary" and has a locale of 0 in the source code. * Does "WIN" refer to whatever the Windows code page is? TDbf translates to/from code page 1252. * TDbf uses 0x37 aka DB850US0. This is code page 850 and locale 1033. * This...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: - BDE uses 0x57 aka DBWINUS0. This s commented as "Ascii: Binary" and has a locale of 0 in the source code. -- Does "WIN" refer to whatever the Windows code page is? TDbf translates to/from code page 1252. - TDbf uses 0x37 aka DB850US0. This is code page 850 and locale 1033. --...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: - BDE uses 0x57 aka DBWINUS0. I believe "WIN" refers to whatever the Windows code page is, meaning that there will be no translation. This is supported by the generic name "ANSI" and the discussion, the "Ascii: Binary" comment in the source code, and the locale 0 in the source...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: - BDE uses 0x57 aka DBWINUS0. I believe "WIN" refers to whatever the Windows code page is, meaning that there will be no translation. This is supported by the generic name "ANSI" and the discussion, the "Ascii: Binary" comment in the source code, and the locale 0 in the source...
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: - BDE uses 0x57 aka DBWINUS0. I believe "WIN" refers to whatever the Windows code page is, meaning that there will be no translation. This is supported by the generic name "ANSI" and the discussion, the "Ascii: Binary" comment in the source code and the locale 0 in the source code....
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? On an en-us machine: - BDE uses 0x57 aka DBWINUS0. I believe "WIN" refers to whatever the Windows code page is, meaning that there will be no translation. This is supported by the generic name "ANSI" and the discussion, the "Ascii: Binary" comment in the source code and the locale 0 in the source code....
-
This discussion has a list of language IDs. https://stackoverflow.com/questions/52590941/how-to-interpret-the-language-driver-name-in-a-dbase-dbf-file Do you know what "Baltic" is intended to refer to? If this discussion is accurate, it suggests there may be multiple problems with the language ID mappings in TDbf. I noticed, for example, that on an en-us machine: - BDE uses 0x57, which is described as cp1252 and ANSI, but TDbf describes it as "binary" ANSI. Whatever that means. - TDbf uses 0x37,...
-
Fix double reading of Version in Tag Header
-
Override abstract method
-
Fix lock offset
-
Fix setting sequential record number to BOF/EOF
1 >