I'm using the following global to pull links from another GLinks installation where the data is held in the same table.


I've copied the links2 def file and labelled it links1_links2.def The global is finding the .def file

I add the tag <%altlinks%> to the rightside template.

I copy the 'feature.html' template.

This code works fine in installations on the same server but will not work on different servers.

Can anyone see where I've gone wrong?

Thanks.

Hi,

If I am understand correctly.

Most of the databses.def in the admin/defs use 'localhost' to connect to database. You can edit the copied def and change to that server ip. And you should enable that server to allow connect from outside(i.e. the server is calling the global).

Hope that helps

Cheers,

Cheers,

Dat

Programming and creating plugins and templates
Blog

Hi

Thanks for replying.

The database server & table are the same for both installations so shouldn't need changed?

Hi,

Although they are the same, but if the Mysql is on other machine(e.g defferent IP or hostname), you should change the database.def. As you know, whenever, Glinks try to load a table, it needs to connect to the actual mysql database.

Hope that's clear.

Cheers,

Cheers,

Dat

Programming and creating plugins and templates
Blog

Thanks. I've just checked the details in database.def and they point to the right server/table with the right login and host info.

Try this where the path /mysite/cgi-bin/admin should be the path to the other installation of Links.

sub {
use lib('/mysite/cgi-bin/admin');
my $search_db = GT::SQL->new('/mysite/cgi-bin/admin/defs')->table('Links');
my ($output,$sth,$feature);
my $search_db = $db->table('Links');
$search_db->select_options ('ORDER BY Add_Date DESC');
$sth = $search_db->select ( { isFeature => 'Yes'});
while ($feature= $sth->fetchrow_hashref) {
$feature->{'detailed_url'} = "$CFG->{build_detail_url}/$feature->{'ID'}$CFG->{build_extension}";
$output .= Links::SiteHTML::display ('feature', $feature);
}
return $output;
}

There are a couple of threads about loading data from other tables, and the post above is one of the routines that was developed.

The "trick" is grabbing another database object using the path to that DEF area. The files must be accessible on the same Unix server, is the only limitation. No work around for remote servers has been offered, but would probably require some sort of .cgi to take the request, handle it, and return the data, like an xml feed.

http://www.gossamer-threads.com/...i?post=255327#255327


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Thanks Folks

I've tried these but am not getting anywhere... it was previously working fine when the sites were both on the same server.

When I tried to make a second directory for the defs & place the Links.def from the other installation in it, the programme switched all the defs over to using this directory.

I'm dropping the problem for now.

I think you are trying to confuse a few things, in how it's operating.

The paths have to be Unix accessible from each server. I don't think you can load a set of defs from a directory not on that server, but it might be possible (eg: copy the defs you want to to a defs2 directory, for example).

If you load that table, to $DB2, then anything that $DB2 is used as a handle for will use that other set of defs and tables.

Any operations on that will operate on those tables. Any variables initialized as pointers to those objects will also operate on those tables. You need to grab another data object, $DB to operate on your local tables.

You need to copy any data to $DB if you wanted to save it in your local tables, where $DB was the local defs.

In theory, the .defs should only tell the object where to find the table, how to access it (eg: password) and then how to load it (the defs in the directory).

But, that object will now only operate on that set of tables.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Thanks

I think the problem is because the installations are on a different server than when I previously used this.

The setup is:
All GLinks installation tables in the same database.
Copied def from GLinks 1 to GLinks 2
Told the programme which def to use in global.

Have used the same setup before but this time, although the installations are on the same server. they don't seem to be able to access each other's paths.

this doesn't work because the programme then looks for all defs in this directory and nothing works.

My theory had been that because the tables were all in the same database, and I provided the def file called via the global, that the data should have been available.

Never mind, another step on the learning ladder!

I think something else is going on here.

Or, one of us is not understanding the other.

You *can't* just copy the def file, you have to copy the whole defs directory to a new directory.

When you initialize your $DB2 object, you give it the new path to your defs. It will pull the information out of the database.def. You need to edit that file to show the new path to where you put the files. For instance, if your path was:

/path/to/defs/on/other/server/defs

and you copied it to

/path/to/defs/on/my/new/server/defs2

You need to edit the def_path variable in the database.defs file to reflect that.

When you do that, $DB2 should be pulling the information about the tables from the
/path/to/defs/on/my/new/server/defs2

Not from the
/path/to/defs/on/other/server/defs

$DB and $DB2 have different parameters in their objects, and pull the def file information from different places.

If it's not working that way, alex or brewt will have to address why.... But that is how it should work. The objects are independent, and each object you create will have it's own parameters set. The program shouldn't care about what code is running, as long as when it loads a table it gets the right def file to pair up with it.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

I think I'm understanding you.

But if I set the defs file path to
for $DB2 and

then the programme looks for all the defs files at this path- and cannot find the originals. It must change something else in the files.

Ok, how about doing this:

Set $DB (already done in initialization)

Set $DB2 to the new path.

Set $DB3 to the path that $DB is set to.

If something is "Sticky" in the object methods, that will immediately reset them, and $DB2 should still have the initialized object.

But, if you want, I'll look at your code to see what's going on. Just make sure that when you call your objects, you realize which set of tables you are working with. That is, your $DB2 object is only used for the "remote" table, and anything it touches, will be "remote." You need to use the $DB object for anything local, and use temporary variables to pass things between -- avoid POINTERS or REFERENCES as that might be the problem. You actually want to pass the _DATA_


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.