That is the FULL install file, which will NOT properly patch your
10.10 solution. Two options:
1) Remove your old engine completely, then reinstall the full download
you have already.
2) Download the WGE patch as a separate file from
http://www.pervasivedb.com/Database/MaintenanceReleases/Pages/PervasivePSQLv10SP2_Patch.aspx
and update your 10.10 to 10.20 that way.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach at (no spam) goldstarsoftware.com
http://www.goldstarsoftware.com
*** Pervasive Training - October 2009 in Chicago ***
Michael Schwarz wrote:
Hi,
at (no spam) BtrieveBill: Many thanks for fast reaction! As You suggested, I wanted
to try Pervasive v10.20, but I couldn't find it. From Pervasives web
site I downloaded a file named "PSQL-Workgroup-10.20.030.000-win.x86",
but when installing it, it identifies itself as "Pervasive PSQL v10.10
Workgroup (32-bit)". After installation "Control Center" shows version
"10.10.125.000". Is there an other installation file for version 10.20?
My colleague already contacted the pervasive support, who forwarded the
problem to the developers.
Kind regards,
Michael
I agree -- it should never cause an engine crash. I recommend
contacting Pervasive directly via their support group and logging a
formal incident. This will get you a bug fix (when it is available).
They charge $250 to log an incident, but if the problem is a bug in
their code (and this looks like it is), then they usually refund it.
Be sure to try v10.20 before calling in, just in case...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach at (no spam) goldstarsoftware.com
http://www.goldstarsoftware.com
*** Pervasive Training - October 2009 in Chicago ***
Michale Schwarz wrote:
Hi,
I've got a serious problem: The following query reproducibly crashes a
PervasiveSQL-Server:
SELECT
length(sp_titel),
case length(sp_titel)
when 0 then zusatz
else sp_titel
end
FROM
STAMM
WHERE
day(gdatum) = 10 and month(gdatum)=8
STAMM is a view defined as follows (I replaced parts not used in query
with "[...]", otherwise statement would be very large):
CREATE VIEW "STAMM" AS
SELECT [...] "T1" ."ZUSATZ" , [...],"L_1" ."KLARTEXT"
"SP_TITEL" ,[...]
FROM "T_STAMM" "T1" LEFT JOIN "L_CO704" "L_1" ON "T1"
.."SP_TITEL" = "L_1" ."PC__AINC" [...]
WHERE "T1" ."PC__SKZ" = 0
"T_STAMM" and "L_CO704" are tables defined in database. These tables
have been created by an special program with "CREATE TABLE [...] IN
DICTIONARY USING [...]" because of corresponding Btrieve files are
filled by another application of us using Btrieves interfaces.
During build of SQL data definition files Btrieve type "String" (0)
was
mapped to SQL type "CHAR", although unused trailing characters are
filled with binary zeros by our application. I tried using VARCHAR
instead of CHAR, but then the last character of an full filled
field/column was truncated.
I was able to verify the problem with PervasiveSQL 9.7 and 10.10
(Summit, both workgroup engines).
Does anybody knows how to avoid or solve this problem? There could
be an
error message whenever statement is not supported, but IMHO server
should definitively not crash in that case.
Many thanks in advance,
Michael Schwarz
|
|
