В Сб., 10/03/2012 в 12:48 +0100, Dimitry Sibiryakov пишет:
> 10.03.2012 12:08, Alexander Peshkov wrote:
> > in a form as server sees them
>
>BTW, I strongly believe that when the doc writer typed it "as server sees
> it", (s)he
> mean only drive letter and patch, but not encoding. Particular
10.03.2012 12:08, Alexander Peshkov wrote:
> in a form as server sees them
BTW, I strongly believe that when the doc writer typed it "as server sees
it", (s)he
mean only drive letter and patch, but not encoding. Particularly because native
English
speakers used to have no idea about encodin
10.03.2012 12:08, Alexander Peshkov wrote:
> But should same conversions be applied to SPB, provided
> that file names must be provided by client already in a form as server
> sees them?
Of course it should. Just because server can have different ANSI codepage.
In this case
client physically
В Ср., 07/03/2012 в 18:32 +0100, Dimitry Sibiryakov пишет:
> 07.03.2012 16:41, Alex Peshkoff wrote:
> > Therefore the question
> > is - does server-side encoding also fit in to that 'as_server_ can see it'?
>
>I would say that if you use unicode routines for file I/O you won't miss.
>
No pr
07.03.2012 16:41, Alex Peshkoff wrote:
> Therefore the question
> is - does server-side encoding also fit in to that 'as_server_ can see it'?
I would say that if you use unicode routines for file I/O you won't miss.
--
SY, SD.
-
On 03/01/12 20:48, Adriano dos Santos Fernandes wrote:
> So, the password (and all other data) is converted if
> isc_dpb_utf8_filename is not used. This may have bugs, specially in the
> services mode, I'd say.
When converting strings in DPB to UTF8, we touch not only password but a
number of o
On 03/02/12 20:03, Björn Reimer wrote:
> Hello
>
> Will it be possible to use more than 8 digits for a username from fb 3.0
> without writing an own plugin?
>
You may use up to 31 characters with any FB version. 8 chars was
password limit.
--
Hello
Will it be possible to use more than 8 digits for a username from fb 3.0
without writing an own plugin?
--
Björn Reimer - RRZE
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes
On 03/01/12 21:09, Dalton Calford wrote:
> Quick Question in regards to passwords and user names in general,
>
> Has the max length of User names, Passwords and System objects been
> increased in FB3?
>
Password's length was increased, currently it's efficient length is 20
bytes (longer passwords
On 03/01/12 20:48, Adriano dos Santos Fernandes wrote:
> On 01/03/2012 13:39, Adriano dos Santos Fernandes wrote:
>> On 01/03/2012 13:26, Dimitry Sibiryakov wrote:
>>> 01.03.2012 17:17, Adriano dos Santos Fernandes wrote:
I understand a problem, but please talk about the solution you're
Quick Question in regards to passwords and user names in general,
Has the max length of User names, Passwords and System objects been
increased in FB3?
With a 31 Char limit and UTF8 some users can be severely limited in their
use of FB unless the limits are increased substantially.
regards
Dalt
On 01/03/2012 13:39, Adriano dos Santos Fernandes wrote:
> On 01/03/2012 13:26, Dimitry Sibiryakov wrote:
>> 01.03.2012 17:17, Adriano dos Santos Fernandes wrote:
>>> I understand a problem, but please talk about the solution you're
>>> proposing. What is the moment(s) a password should be converte
On 03/01/12 20:17, Adriano dos Santos Fernandes wrote:
> On 01/03/2012 12:29, Dimitry Sibiryakov wrote:
>
>> Because password encryption method is going to be changed in 3.0, isn't
>> it too late to
>> suggest to convert password into UTF-8 before encryption?
>> Imagine two user environme
On 01/03/2012 13:26, Dimitry Sibiryakov wrote:
> 01.03.2012 17:17, Adriano dos Santos Fernandes wrote:
>> I understand a problem, but please talk about the solution you're
>> proposing. What is the moment(s) a password should be converted, and
>> from what to UTF8?
> Sorry, but I don't have a s
01.03.2012 17:17, Adriano dos Santos Fernandes wrote:
> I understand a problem, but please talk about the solution you're
> proposing. What is the moment(s) a password should be converted, and
> from what to UTF8?
Sorry, but I don't have a solution for this problem. I would say that
password m
On 01/03/2012 12:29, Dimitry Sibiryakov wrote:
> Because password encryption method is going to be changed in 3.0, isn't
> it too late to
> suggest to convert password into UTF-8 before encryption?
> Imagine two user environments on Linux, one has locale win1251 and
> another utf-8.
> Pa
01.03.2012 16:55, Dalton Calford wrote:
> Why not have all password connections use a single default encoding
> regardless of the
> overall codepage that is in use?
The problem is not in the password itself, but in typing it on keyboard.
--
SY, SD.
---
Why not have all password connections use a single default encoding
regardless of the overall codepage that is in use?
Select a codepage, make it the password default, have the client libraries
understand this and you are no longer worried about differences in client
code pages.
On 1 March 2012
On 03/01/12 19:29, Dimitry Sibiryakov wrote:
> 01.03.2012 16:27, Alex Peshkoff wrote:
>> That's nightmare:-)
>> But something like KOI-8 is quite possible.
>Even more possible win1251 in Windows GUI vs cp866 in console.
Yes. Absolutely correct.
--
01.03.2012 16:27, Alex Peshkoff wrote:
> That's nightmare:-)
> But something like KOI-8 is quite possible.
Even more possible win1251 in Windows GUI vs cp866 in console.
--
SY, SD.
--
Virtualization & Cloud Manage
On 03/01/12 19:07, Dimitry Sibiryakov wrote:
>Hello, All.
>
>Because password encryption method is going to be changed in 3.0, isn't it
> too late to
> suggest to convert password into UTF-8 before encryption?
>Imagine two user environments on Linux, one has locale win1251
That's n
Hello, All.
Because password encryption method is going to be changed in 3.0, isn't it
too late to
suggest to convert password into UTF-8 before encryption?
Imagine two user environments on Linux, one has locale win1251 and another
utf-8.
Password, containing non-Latin symbols, create
22 matches
Mail list logo
