Solution works in Developer but not on server when deployed

Classic Servoy
1

Hello again all!

We have a solution that works nicely in developer, but when we deploy it to production, it fails with an error with a relationship (developer shows now relationship errors)

We believe that the repository has some old lingering references that no longer apply, yet we have had no luck getting a fresh start.

Originally, we had a solution named:

mod_xcart

(note, this is a database that works as the backend to a shopping cart – we have integrated our servoy solution to interface with the mysql files… makes managing a brick and mortar and a web store much easier)

So the shopping cart company came out with a new version and changed a bunch of database columns. (grr)

So, we had to upgrade our solution to point to the new data structure.

We then duplicated our mod_xcart solution via the steps outlined in the user guide and then had a solution named mod_xcart_42

We then changed all the necessary database refs and in the development environment, things work without errors.

On our server, we originally had mod_xcart installed. We deleted it via the app server interface.

We imported the new soluiton, mod_xcart_42

That’s how we are still getting the error. We suspect that the repository is holding some old info from the mod_xcart solution. We thought that maybe if we deleted all solutions via the app server and then reimported, that would solve all… but we still get the same result. We also tried the -updgradeRepository step… but that didn’t seem to help either.

Hopefully this makes sense. Any ideas on what we could try? Is it safe to clear out any tables in the repository? And then try and import again?

Thanks,

Chico

2

Hi chico

Have you checked all your calculations and aggregates following the structure changes and solution duplication ?

I did something similar with some DB structure modifications and relations and forgot to alter references in some of my calc and agg functions which caused me problems until I tracked them down

Cheers
Harry

3

Thanks Harry,

I did check that out, and we aren’t using any calcs or aggregates against that solution. :(

We’re still searching. But do you know… are there tables in the Repository that you can wipe clean and then reimport a solution through the app server?

-chico

4

What happens in a clean install of servoy server?

5

Hi jcompagner…

We have not tried the clean install… but have tested it on our testing server and it works as it should.

Is it ok to clear out the servoy_elements and servoy_root_elements table and do a solution import? Is there any risk to doing that? As long as we’re just reimporting our current solutions?

Through some digging, I’ve found some servoy_elements that have a -1 for the parent_element_id and if I search the UUID in developer, the UUID matches up with elements in our older mod_xcart.

Are we barking up the wrong tree?

-Chico

6

you could clear it out and try that
But i think then it is better to just generate a clean repository db and create the repository tables and then import

7

We’ll try that tonight. Being that we used to be FileMaker kids, the repository db is still a bit confusing… if we create a new repository db… can we still launch the server app and use it to reimport the solution? Meaning… the app server can launch on an empty repository db?

Chico

8

yes with -upgradeRepository first it will generate the tables.

9

Ok, we did all that, and we were barking up the wrong tree… the issue still persists.

We have submitted this as an issue to the Servoy team, but here’s what we found:

Our solution integrates with a shopping cart solution called x-cart. Because we have a saas environment, when we get a customer that integrates their cart, we add a new server to our app server that points to their xcart database.

Next, we have a headless client that we set up to launch a solution that syncs information from our saas db’s to the user’s x-cart db’s. We setup a batch process that passes the proper arguments … one of which is an argument that specified the database server.

So, when the batch launches, it will do a switch server command and move the original data source from xcart_4_2_x to consign_cart. (xcart_4_2_x is a db on our db server, consign_cart is the db on the user’s web server) Both db’s have the same data structure.

For some reason, when we run our process methods after the switch server, there are two tables that cause an error in relationship, but if we don’t do the switch server and the methods run against the original db, we don’t get the error.

You can reproduce this be going to:

http://ch.us1.paygosaas.com:8080/

When prompted for a solution, select the mod_web_xcart_42x.jnlp

To test working situation:

When prompted for CJI ID, enter: 241
When prompted for Code enter: servoy#
When prompted for db name enter: paygo_xcart_4_2_x

A window will appear that contains a tabpanel. All of the tabs are relationships from our database to the x-cart database… each tab representing a different table. You will notice that when you click on the images_cart_t and images_cart_p, things work as normal.

To see the error, close the solution and reopen using these criteria:

When prompted for CJI ID, enter: 241
When prompted for Code enter: servoy#
When prompted for db name enter: consign_cart

Now if you click on the you’ll get the error in relationship with the server popping an error that says ‘consign_cart.xcart_images_t’ doesn’t exist

But it DOES exist. :(

All I can think is that for some reason, something doesn’t like that naming scheme… but I’m confused. Any ideas?

10

Chico,

This error is not an error from Servoy saying it can’t find the relation, this error is an error from the database saying there is an issue with the sql

com.servoy.j2db.dataprocessing.DataException: Table ‘consign_cart.xcart_images_t’ doesn’t exist
at com.servoy.j2db.dblayer.DBDependentHandler.Za(DBDependentHandler.java:207)
at com.servoy.j2db.persistence.Server.translateSQLException(Server.java:239)
at com.servoy.j2db.dataprocessing.SQLEngine.performQuery(SQLEngine.java:682)
at com.servoy.j2db.dataprocessing.SQLEngine.performQuery(SQLEngine.java:401)

Check the logs, there must be an sqlexception and the failing query.

Rob

11

Thanks Rob… but why does it happen only when we do a switchserver to a new database? It works if we’re using the existing database.

We’re using only Servoy to do this also, so servoy is generating the sql.

-chico

12

Chico,

My first hunch is that the 2 datamodels are not completely in sync.

Look at the logs, get the failing query from there and try to run it directly in the 2 databases with a db tool.
Hopefully you can see why it works in 1 and not in the other.

Rob

13

Hi Rob… ok… dumb question, but which logs are going to show the queries we’ve run?

14

By default /path/to/servoy/application_server/servoy_log.txt on the servoy-server running the solution

Rob

15

I’ve checked there many times and nothng is jumping out at me… I’ll get an sample and post it up.

16

Chico,

I think an example won’t help you, the problem is in the database.
For the same reason it works in your developer, the sample will work elsewhere.

Have you checked the ch.us1.paygosaas.com server?

Rob

17

Hi Rob,

The db structures look the same… i’ve looked them over and over and over.

Any other ideas?

18

are you really sure that it is the same?
are you sure that you look at the same db server the servoy server connects on?

Can you really run the query that goes wrong on your db in another tool? (and then on both db servers)

19

Yes, I know I have the right database because we run some methods before the error and inserts work fine on other tables.

It’s just the tables named: xcart_images_t, xcart_images_p… basically, any table that has that naming scheme of xxxx_images_x.

And the initial error is that the table doesn’t exist… yet it does exist.

The query does work too if I run it in another tool.

Chris

20

chico:
The query does work too if I run it in another tool

Chris,

So you found the failing query from the logs?
Can you show it including the stacktrace from the log?

Rob