Tim,

I have downloaded 1.05 trial and it seems like there's something
wrong either with me or with it.
The following SQL (which surely use to work before):

SELECT
  NAME, DESCRIPTION, VERSION, ENCRYPTED, INDEXPAGESIZE, BLOBBLOCKSIZE,
  MAXROWBUFFERSIZE, MAXINDEXBUFFERSIZE, MAXBLOBBUFFERSIZE
FROM INFORMATION.TABLES
ORDER BY NAME

now returns the following strange error:
ElevateDB Error #406 Invalid temporary table identifier
'CONTEXT8441640DBA7199CBE2FD44229BFD73528DA0503B143'

The database name (randomly generated from GUID) is:
DBA7199CBE2FD44229BFD73528DA0503B143'

The name seem perfectly fine, at least previous versions of EDB
allowed it and were able to execute the above SQL fine. Is there
any limitation as to the length of it? Are you considering changing
it back (i.e. would you consider this to be a bug (?), because it seems
like a valid database name should produce valid temp table name, so
if it accepts a database name like that, the error above should not
happen).

Also, trying to run EDB Manager after uninstalling and reinstalling
everything I was unable to connect the Default (or any other created
local) session. It gave me the following error:
---------------------------
ElevateDB Manager
---------------------------
ElevateDB Error #600 File manager error (Cannot create file
C:\DBEngines\ElevateDB1\Additional\utils\edbmgr\EDBConfig.EDBCfg (OS Error: The
system cannot find the path specified))
---------------------------
OK
---------------------------
There's no such folder in my system, it is installed into
C:\DBEngines\ElevateDB\Additional\utils\edbmgr\
and I have no idea where it takes this information from and
how to correct it. I was trying to search registry, but was unable
to find anything there. Finally I was able to locate the ini file
under
"C:\Documents and Settings\Mike\Local Settings\Application Data\Elevate
Software\ElevateDB Manager\"
and correct settings there, however you should still probably
look into the problem and maybe update that file when installing
the software.


Regards,
Michael

Michael,

> now returns the following strange error:
> ElevateDB Error #406 Invalid temporary table identifier
> 'CONTEXT8441640DBA7199CBE2FD44229BFD73528DA0503B143'
>
> The database name (randomly generated from GUID) is:
> DBA7199CBE2FD44229BFD73528DA0503B143'


According to the manual the max identifier length is 40 characters - I
think that slipped in with one of the point releases however.

Eryk

Eryk,

>> now returns the following strange error:
>> ElevateDB Error #406 Invalid temporary table identifier
>> 'CONTEXT8441640DBA7199CBE2FD44229BFD73528DA0503B143'
>> The database name (randomly generated from GUID) is:
>> DBA7199CBE2FD44229BFD73528DA0503B143'
> According to the manual the max identifier length is 40 characters - I
> think that slipped in with one of the point releases however.
Possibly, however, that's not the point. The database name
(above) is considered to be valid by engine, however the engine then
produces the name for temporary table which probably exceeds the limit.
I'd say - either lower down the limit for database name or rethink the
way temp table name is generated. I think concatenation is just not
a very good idea.


Michael

Michael,

<< Possibly, however, that's not the point. The database name (above) is
considered to be valid by engine, however the engine then produces the name
for temporary table which probably exceeds the limit. I'd say - either lower
down the limit for database name or rethink the way temp table name is
generated. I think concatenation is just not a very good idea. >>

Actually concatentation is the only way to guarantee a unique temporary
table name in a (possibly) shared network directory.  I'll see about
removing the limit for the temporary table names since they aren't included
in the catalog's information schema tables anyways, and that was the reason
for the limit in the first place.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> << Possibly, however, that's not the point. The database name (above) is
> considered to be valid by engine, however the engine then produces the name
> for temporary table which probably exceeds the limit. I'd say - either lower
> down the limit for database name or rethink the way temp table name is
> generated. I think concatenation is just not a very good idea. >>
>
> Actually concatentation is the only way to guarantee a unique temporary
> table name in a (possibly) shared network directory.  I'll see about
> removing the limit for the temporary table names since they aren't included
> in the catalog's information schema tables anyways, and that was the reason
> for the limit in the first place.
Another simple way is to produce it based on GUID (just like I did
then you are guaranteed not to exceed the limit and be always unique.

Regards,
Michael

Michael,

<< Another simple way is to produce it based on GUID (just like I did
then you are guaranteed not to exceed the limit and be always unique. >>

Good solution.

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com