tables added to database not visible from other substacks

Creating desktop or client-server database solutions?

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

dochawk
Posts: 43
Joined: Wed Sep 02, 2009 9:29 pm

Re: tables added to database not visible from other substack

Post by dochawk » Tue Jun 05, 2012 1:33 am

phaworth wrote:Hi hawk,
Well, not sure what I'm doing different than you but everything looks fine to me.

I had to change tDatabasePath to be valid on my computer but after that the outwin field lists both tables each time you put something in to it. I looked at both databases in another program and they both had both tables in them.
Both have always been created, as far as I can tell. And in the creating routine, they're visible. However, at checkpoint 5, you see both fields when I put it to the output window by script. However, at that point, stepping through, if I type the command into the message box, I get a different result--only dna is visible. This is the case as soon as the return from crdna (and possibly inside; I forget).

So as soon as it returns from crdna, I try the message box. Only dna is visible. I step over, and it shows both dna & dinfo from the script. I then do it from the message box, and it only sees dna.

IN this situation (and when it arises in other scripts), I can manipulate table dna, but attempting to manipulate dinfo throws errors--except that I can delete dinfo from places that can't otherwise see it. If I try to delete a second time, it throws an error (as it should).
One problem may be that you are not declaring your globals in all your scripts. I see them in the stack script of your main stack but I don't see them declared anywhere else. That might be OK if you only reference them in handlers in your main script, but if you try to access them from any other scripts, there'll be problems because the script won't know anything about them.
Shouldn't the declaration at the top of the script, before any handlers, handle all the handlers in that stack?
For example, trying to execute revDatabaseTablenames(debtordb) in the message box returned an error because debotordb wasn't available to it as a global, but if I put revDatabaseDebtorDB(1) into the message box, it listed both your tables.

----Edit------
If I type "put revDatabaseTablenames(getdebtorDB())" into the message box, it displays both tables.
--------------
Really? I don't get it with either one of them!

put debtordb, getdebtordb()

from the message box yields

2,2
I also looked at both databases you create with an external program and they both contained both tables, so I'm not sure why you think they only have one table in them.
I know that they *do* have both tables; but revDatabaseTablenames() doesn't see them, and a SELECT on that table throws an error.
I still think you shouldn't be dealing with the structure of your database in your application. There are plenty of utilities out there that will create an sqlite database for you so all you have to do is open it in your application. I'll declare a vested interest in that statement because I sell such a utility. It's called SQLiteAdmin and you can find it at http://www.lcsql.com. There's a 30-day trial available for download. Some of the functionality is not available in the demo version but if you open your database(s) with it, you'll see that both tables are there and you will be able to add other tables and/or columns if you need to.
There's not going to be just one incidence of the database.

An attorney will buy my program, and need a new database for each client's petition.

.
The program needs to be able to deal with the database structure, and update it to accommodate additions to the program

Making the attorney use another program to create a database for each case would be a non-starter.

Some firms will have a few new ones on a daily basis, others maybe only once a month.

Also, I'm using sqlite for the moment simply because it's there; I expect it to generally use postgresql or mysql, especially in a cloud configureation.
Hope that helps,
It does; thanks.

hawk

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: tables added to database not visible from other substack

Post by phaworth » Tue Jun 05, 2012 6:09 pm

Well I guess I'm not sure where to go from here. I am not seeing the problems you're describing, unless I'm misunderstanding what you're doing.

I added a button to your t_file_control stack with the following code:

Code: Select all

on mouseUp
   answer revDatabaseTableNames(getdebtordb())
end mouseUp
After opening your cook database, I click that button and it shows both tables in place.

I also added a button to select data from dinfo and display it:

Code: Select all

on mouseUp
   put revDataFromQuery(,,getDebtorDB(),"SELECT * FROM dinfo") into tData
   answer information tData
end mouseUp
It displayed empty of course because there's no data in the tables but if there had been a problem, it would have displayed an error starting with revdberr.

In another button, I did the same thing on the dna table:

Code: Select all

on mouseUp
   put revDataFromQuery(,,getDebtorDB(),"SELECT * FROM dna") into tData
   answer information tData
end mouseUp
Same result, no error message.

Pete

dochawk
Posts: 43
Joined: Wed Sep 02, 2009 9:29 pm

Re: tables added to database not visible from other substack

Post by dochawk » Thu Jun 07, 2012 5:26 pm

As that stack is currently set up, anything you do from a substack with a script seems to see everything--but if you type the identical command into the message box, you get a different result.

I first encountered this with the script in a substack that isn't in this example.

RIght now, I have it working in my main program with the extra global declarations--but that shouldn't be necessary.

I suspect that I've backed into a bigger bug of some type, and that I'm only triggering it.

1, debtordb, and getDebtorDb() all resolve to 1 in the above example. A reference to the database with something that resolves to 1 should get the same database, no matter how it was created. The problem here is not that the database isn't always found, but that under some circumstances, the entire database is not seen.

I'm going to give up on figuring out why; and just use the extra declarations.

Thanks to all

hawk

Post Reply