Serious bug prevents me from using SC

This has been reported to Net Make Tech Support, but so far nobody has found a solution.
I have project where at some point I used 2 connections to 2 different databases (MySQL and SQLite).
I need to deploy the project on a server without the MySQL connection (kepping SQLite connection only).
When I go to deployment on the screen which asks for connection it shows both connection strings (one for MySQL and one for SQLite). MySQL connection was removed some time ago. I re-asigned connection strings and regenerated the whole project but SC still keeps 2 connections. Upon suggestions from Tech Support I removed files from …/tmp foled, and I removed files from …/app/MyApp folder - no luck.
When I try to run a project on the server it asks me for 2 connections (while obviously should be only one). I really don’t know where SC stores this information but I know that SC is well known for this type of ugly behavior.

This seems like very serious bug, and at this point I simply cannot use Scriptcase at all. It is being almost 2 weeks…

Please report it to the developers and release a bug fix ASAP.



You did completely regenerate and redeploy your code??


I recommend you to try rr suggestion.

Issue reported to our bugs team.

Bernhard Bernsmann

A workaround.
On production you must define the 2 connections for the same db… easy.
But boring… of course

no 2 connections, because at the moment only one dB exists.
Yes I regenerated the code, removed 2nd connection string completely and it still shows up on deployment screen.
I copied procedures to the new project but no luck.
Then I started to copy Apps in chunks and noticed there is a group of about 20 Apps that causes this problem when copied. Without them all works fine. I haven’t narrowed down which exactly App is causing a problem but I suspect if could be only:
1- lookup field that uses old connection string
2- sonnection listed in the code

2nd is out of scope, I do not use connection string anywhere in the code
1st is possible, but how the hell SC would keep any old connection string if I run Express Update on: Connection and FieldConnections ?


After 3 weeks of strugling still cannot deploy my project. Better yet I have another one (this one is MySQL only), which at some point have had 3 different connections defined. After I removed the other two before deployment exerything got messed up. Now again when I try to deploy the project I see 2 connections instead of one. Another workds my second project is useless now! aaghahghghghghrhghahrh!!! I’m soooo mad!

I just checked my messages in NM Tickets and they confirmed they could reproduce this bug, but so far no solution !!!


As I have suggested, I had the same problem and the only workaround is to define these connections to the same database.
It 's just to cheat the system and complete these “ghost connections”. I know it’s a mistake, but if you want to publish your application you do not have many other alternatives.

So: conn_A ->>> DBPROD , conn_B >>> DBPROD and so on…


OK, I understand your point as workaround. So I’m assuming you recreated the second connection and pointed it to the same database as the first one - right ?
Another words - you have 2 connection names with the same connection strings pointing to the same database on the production server. Correct me if I’m wrong.

I will try your suggestion
Well,… at least god to know it is not only me :frowning:

to give others who have this problem a hint, what is wrong I tell you what happens when I Export/Import (or rather Copy) Apps.

I used COPY TO ANOTHER project feature.

  1. I copied about 30 Apps initially from Project1 to Project2
  2. Generated, deployed,…al works fine
  3. I COPIED (added) another 20 Apps, the all of the sudden got the same problem with 2 connections.

The conclusion is that there must be something in the particular App that stores the Connection Name.
why is it so? I do not know, or Express Edit feature does not correctly update everything. If it does then there should be no other connections anywhere in the project available - right?

QUESTION: when I create Project2 (blank), then copy Apps from Project1 to Project2, what happens to the database tables for that project. If the (Internal SC )tables are copied the the connection column will be copied as well.

THIS IS VERY SERIOUS BUG and I WISH NETMAKE could participate in this thread.


This is exactly what I do.

I tried also to investigate the faulty connection in the ScriptCase’s tables and I found one reference in the “sc_tbcmp” table.
Analyzing the context form I discovered that the problem was in a lookup field.
This application was copied from another project and at this point my suspicion ( almost a certainty ) is that when you copy applications from one project to another, SC does not reset the default connections on the lookup fields.
In fact, after changing the connection on the lookup and forcing the correct one, saving and recovering the connection to default, everything is ok and when I deploy only a single connection. (!!!)

Something that maybe can help SC solve the problem?

Yes, Arthur and I tried to find the issues in the repository sqlite db. Problem is that playing with this file is not that obvious due to lack of documentation. Always make a full bakcup of everything so you can restore if you mess up. In the case of Arthur there where more tables containing bad references.

In general I would welcome some tools to be able to investigate the repository. That way you can repair outside of the application. In case of a lookup: if you have disabled the lookup the data is not removed but remains, only it’s unseen. This can generate a lot of unexpected problems.

Albert - I thank you for your help on that, and your expertise, although this problem still hasn’t been solved. I simply did an Export/Import to a newly created Project, App after App and now it is working, but I have spent (or I should say) wasted humongous amount of time doing this. The was the only way. I’m surprised there is no reponse to this problem from Net Make on the forum, as this is very serious issue.