I have updated my local machine form 2.14 to 2.23 (before I do my production machine).  I am having an issue with the Elevate.ElevateDB.Data.dll.  My web site can access the data if I keep my .NET 3.5 web site code and use 2.14 Elevate.ElevateDB.Data.dll.  If I update to 2.16+ I get a 501 error cannot login. I did the UNICODE FIX program also.

The EDB Manager is 2.16+ (currently 2.25) and I have my session as UNICODE.  I did not migrate my database to UNICODE (Assume was/is still ANSI). If I set the session an ANSI I get a #1100 error cannot establish a connection.

Am I required to migrate my database to UNICODE? Or am I missing a setting in my connection string now.

connection string is

"name=cnconnect;     type=Remote;uid=User;pwd=secretpw;database=mydatabase;readonly=False;address=127.0.0.1;port=12010;ping=False;pinginterval=60;timeout=180;encrypted=False;compression=0;signature=edb_signature;encryptpwd=ePassword;configpath=D:\data\ElevateDB\Production" providerName="Elevate.ElevateDB.Data"/>

So the Manager works - I can see my data, however using the connection string does not connect to my data.- 501 bad login.

Ron

<< Am I required to migrate my database to UNICODE? Or am I missing a setting in my connection string now. >>

The latter, you're missing the new CHARSET keyword in your connection string:

https://www.elevatesoft.com/manual?action=viewtopic&id=edb2dac&topic=NET_Connection_Strings

What you want to add is this:

charset=ANSI

somewhere in your connection string.  The default is UNICODE, hence your issues.

If you're still having issues after making that change, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>><< Am I required to migrate my database to UNICODE? Or am I missing a setting in my connection string now. >>

>>If you're still having issues after making that change, please let me know.



Adding TYPE=REMOTE; CHARSET=ANSI to my connection string now gives a #1100 error connection refused.

If I have TYPE=LOCAL; CHARSET=UNICODE in the connection string I can use 2.25 dll.  - however not what I want.

TYPE=REMOTE; CHARSET=UNICODE - gives bad login #501

If I change to a pre 2.16 dll I can get access via my web site program.  

If the edb manager session is set to UNICODE.  I can access my database.  Setting to ANSI I get #1100 connection cannot be established - socket error.

The edbsrvr.ini file in programdata/ElevateDB Server folder has charaterset=1, The edbsrvr.ini in programdata/ElevateDB Server (UNICODE) does not have character set - file is blank.

I have edbsrvr.ini files in Appdata/local also - these I assume are for the elevatdb manager as they contain my session info. Also characterset=1 is set in my session there.

Do you have some sort of utility to check/rebuild config/ini files for errors or incompatible settings?

Ron

Ron,

<< Adding TYPE=REMOTE; CHARSET=ANSI to my connection string now gives a #1100 error connection refused.

If I have TYPE=LOCAL; CHARSET=UNICODE in the connection string I can use 2.25 dll.  - however not what I want.

TYPE=REMOTE; CHARSET=UNICODE - gives bad login #501

If I change to a pre 2.16 dll I can get access via my web site program.  

If the edb manager session is set to UNICODE.  I can access my database.  Setting to ANSI I get #1100 connection cannot be established - socket error.

The edbsrvr.ini file in programdata/ElevateDB Server folder has charaterset=1, The edbsrvr.ini in programdata/ElevateDB Server (UNICODE) does not have character set - file is blank.

I have edbsrvr.ini files in Appdata/local also - these I assume are for the elevatdb manager as they contain my session info. Also characterset=1 is set in my session there. >>

That all seems okay.  It looks like you're using Unicode all-around and that you should be fine without having to specify the character set for either the ElevateDB .NET Data Provider or the ElevateDB Server.

<< Do you have some sort of utility to check/rebuild config/ini files for errors or incompatible settings? >>

That's what the Unicode conversion utilities are for:

(from the Release Notes)

"If you run the utility more than once, you won't do any damage. However, do not re-run the utility after making further changes to the server information. Doing so will risk the possibility of overwriting your changes with the information from the Unicode settings file."

Please email me the edbsrvr.ini file that you're using (support@elevatesoft.com).  Make sure that it is coming from *this* location on disk:

C:\ProgramData\Elevate Software\ElevateDB Server\edbsrvr.ini

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Sorry to reply late.  I have sent the edbsrvr.ini file.



Tim Young [Elevate Software] wrote:

Ron,

Please email me the edbsrvr.ini file that you're using (support@elevatesoft.com).  Make sure that it is coming from *this* location on disk:

C:\ProgramData\Elevate Software\ElevateDB Server\edbsrvr.ini

Tim Young
Elevate Software
www.elevatesoft.com

Ron,

<< Sorry to reply late.  I have sent the edbsrvr.ini file. >>

No problem.

I checked out your edbsrvr.ini file, and you have a non-default server encryption password set.  This was also a new feature in 2.16:

https://www.elevatesoft.com/download?action=info&category=edb&type=edbvcltrial&majorversion=2&version=2.26

(under "Separate ElevateDB Server Password").

The server encryption password would have been set any time that you modified the EDB Server settings using 2.16 or higher, so you wouldn't necessarily have to explicitly modify that setting.  As mentioned in the release notes link above, the default value is copied from the more general encryption password used for everything in EDB prior to 2.16.

You also have the EDB Server set to use Unicode.  If you've always been using ANSI configurations/databases, then this is why you're seeing a connection error - the EDB Server isn't actually starting and is experiencing an error during startup.  You can see this in the logged events for the EDB Server (once you get it back up and running).

So, this is a summary of what you should do:

1) Start up the EDB Server as a normal application (not as a service) and modify the server settings so that the EDB Server is using the ANSI character set:

https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Starting_Configuring_Server

Your encryption passwords (general encryption password and server encryption password) should all still be okay as-is.

2) Make sure that your connection string contains the following:

TYPE=REMOTE; CHARSET=ANSI; ENCRYPTSRVPWD=<EncryptPassword>

where <EncryptPassword> uses the same password that you were using for the ENCRYPTPWD connection string attribute.  You really only need the ENCRYPTPWD attribute with local sessions, and the ENCRYPTSRVPWD attribute with remote sessions.

That should fix everything.  If you're still having issues, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com