> > because it seems as if both midgard systems doesnot behave the same way.
>
> Depends on the repligard config file ou use. I believe the default is
> repligard.xml, and there's another named repligard_withsg.xml which
> will also do sitegroup related work.
>

The latter repligard_withsg.xml has been used. Since you didnot comment
the ambigous behaviour about the sitergroup field it seems _not_ to be a
problem how I removed this sitegroup reference. I replaced every
occurence of <sitegroup>[0-9a-z]*</sitegroup> against
<sitegroup></sitegroup> and the resource allocation error vanished with
it. However the question leaves why I had to do so ?


> > should be found instead of Ctrl-C. Since I couldnot find the correct
> > number I left it out and the import itself seemed to work without error.
>
> This one is significant. Sounds like a bug.
>

Since it looks like a singular occurance in a record_extension of a
xml-file it looks more like a bug in my database than the procedure. The
impact on the target system is not easy to see. Cannot imagine that so
many errors as reported comes from a wrong but single byte. Significance
may be still to be checked.


> If it says mgd_include_snippet is undefined there's something else
> going on; it means the function wasn't compiled in. Did you ever do
> --enable-mgd-preparser? This will indeed exclude this function. The
> 1.4.2 release did not properly rebuild everything if you reconfigured
> without this option. The solution in that case is to unpack a clean
> midgard-php4 somewhere and configure again.
>
>

If you have a look  at http://insight.kn-bremen.de:8080/Guild/home you
will not find mgd_include_snippet missing. Instead the function
bremgard_page_walk that should have been included and that can be found
e.g. using asgard is reported to be undefined. Asgard itself on the site
wouldnot work if mgd_include_snippet would be really missing. The
problem seems to come from the fact that the string to the path in
mgd_include_snippet is not checked or cannot be checked now (Beside the
fact that the path is found by tracking it inside of asgard). I will do
some analysis on it e.g. by moving the bremgard-function.

The midgard release is 1.4.1 07/2001 CVS and has nothing special
compiled.It uses e.g. --with-pagelinks. But it has not compiled on the
target system where the target midgard is used. Instead I installed all
midgard libs and the mod_midgard.so from the source system. Therefor no
error should happen that cannot be found at home where the source system
is working.  I'm afraid the problem comes from the new mixed database.
Now it just looks mixed up sometimes.

> > If you are interested the ruins can be found on
> > http://insight.kn-bremen.de:8080/Guild .
>
> I'd rather have the situation as you had before the install (if you
> have a backup) and try it myself.
>

1:1 backup of the target database should not be required because it
would be rebuild by using the former sitegroup. Although there are many
test-sitegroup on the target midgard only one sitegroup was required  to
be saved. However I think it would be enough to import the xml-file that
was used here into a new database with or without asgard. After creation
of  a new sitegroup e.g. bremen import the bremgard-1.61.xml.gz.  You
find it and repligard.conf at ftp://insight.kn-bremen.de/pub/midgard/xml
.


> If it does, it's simply a repligard bug that needs to be fixed.
> There's nothing in its design that would prevent doing this kind of
> import.
>
>

I felt at the beginning that you may have overseen my xml-patch with
much impact. As long as it expects the source sitegroup link by GUID on
the target system the import won't work.  Otherwise if I would not take
it out repligard stops with the allocation error. What is the sitegroup
link good for during import if the sitegroup should be already addressed
more dynamic by the sitegroup login in the conf file ? However if it's
still really required it may have been an mistake to get it out but then
it looks like a design bug to me.

dieter











---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to