Won't Run Second Time

Charles Yeomans yeomans at desuetude.com
Thu Dec 29 17:51:50 CST 2005


I wonder if the problem isn't your use of dbDatabase.CreateStructure(). 
  For subclasses of VDatabase, you build the database structure in the 
constructor.  It looks like you call dbDatabase.CreateStructure() after 
creating the database, but not when the database is opened next time. 
Try eliminating the CreateStructure call from the App.Open code, and 
instead move it into cDatabase.Constructor.

Charles Yeomans




On Dec 29, 2005, at 5:24 PM, Chuck Pelto wrote:
>
> Maybe. Maybe not. We'll try to get to the bottom of this...quickly. 
> Time is running out. More on that later.....
>
> As I stated, I'm using CreateStructure approach in the example of the 
> SINGLE TABLE...
>
> Project-level classes are:
> cDatabase as VDatabase
> tblTable1 as VTable
> tblTable2 as VTable
>
> App-level properties are:
> dbDatabase as cDatabase
>
> cDatabase-level properties are:
> dbDatabase as cDatabase
> dfTable1 as tblTable1
> dfTable2 as tblTable2
>
> cDatabase-level CreateStructure() code is:
>
> Sub CreateStructure(inStorageType as integer = 1)
>
>   VDatabase(inStorageType)
>
>   dfTable1 = new tblTable1(self)
>   dfTable2 = new tblTable2(self)
>
> End Sub
>
> tblTable1-level properties are:
> field1 as VShort
> field2 as VString
> field3 as VVarChar
> field4 as VObjectPtr
>
> tblTable1-level tblTable1() code is:
>
> Sub tblTable1(inDatabase as cDatabase)
>
>   dbDatabase = inDatabase
>
>   Name = "Table"
>
>   field1 = new VShort("tbl1_field1")
>   field2 = new VString("tbl1_field2t", 50)
>   field3 = new VVarChar("tbl1_field3", 2000)
>
>   field4 = new VObjectPtr("tbl1_dftable2ptr", inDatabase.dfTable2, 
> kSetNull)
>
> End Sub
>
> Table2 follows the same pattern....
>
> App-level Open code is:
>
> Sub Open()
>   dim rslt as boolean
>   dim f as FolderItem
>
>   #if DebugBuild
>   // You can set it to 2 to use DCon
>   Valentina.DebugLevel = EVDebugLevel.kLogParams
>   #endif
>
>   // init database kernel of Valentina
>   Valentina.Init( 10 * 1024 * 1024 )
>   // Open the database
>
>   dbDatabase = new cDatabase
>
>   f = GetFolderItem("dbContacts.vdb")
>
>   // If Database exists we open it, otherwise we create it.
>   try
>
>   dbDatabase.Open( f )
>
>   catch err as VException
>
>   dbDatabase.Creator = "VALA"       // optional
>
>   dbDatabase.Create(f, EVDbMode.kDscDatBlbInd, 32 * 1024, 
> EVOs.kOsDefault)
>
>   dbDatabase.CreateStructure()
>
>   end try
>
> End Sub
>
> As I said earlier, if the app creates a new database, because there is 
> not one already in the folder with it, things work just fine. I can 
> add/update/delete records in the database. I can confirm this, as far 
> as the data is concerned, because the fields are populated when I look 
> at the database file using VStudio. Looking at the values for the 
> database and the tables, I see valid values for them after the Open() 
> function is completed.
>
> However, if I quit and go back into the application and it opens the 
> existing database, I can't access the data therein. All of the tables 
> have 'nil' values for them, as Iook at the variables, after the Open() 
> function is completed.
>
> I'm in a quandry as to why this is happening. It would seem to me that 
> if the database worked fine once, it should work fine again 
> afterwards.
>
>
> On the other hand, speaking of the various 'ways' databases are 
> created, as I said, I used the example from SINGLE TABLE to go by.
>
> I was having entirely too much 'fun' trying to get the 'way' described 
> in the tutorial to get a database operating in Valentina. There, 
> instead of using the   field2 = new VString("tbl1_field2t", 50) call, 
> you use something that reads like this:
>
> call tblPerson.CreateVarCharField( "Name",  1022, EVFlag.fIndexed )
>
> And, I agree, I think it's a misapprehension that there is only one 
> way to create a database structure....
>
>> So my little jab at the way-meister is really a suggestion I guess 
>> that in
>> V3 or V4 it might be better to overhaul all of the documentation to 
>> use a
>> more intuitive and less problematic term such as "style" instead of 
>> "way".
>> But it wouldn't be nearly as homey nor what I consider to be classic 
>> Ruslan
>> as usage of the current term way, which I've come to find very clear, 
>> very
>> distinctively Valentinsh.
>
> My subscription expires in two months. At this point, unless I can get 
> this resolved, I'm disinclined to renew it. We'll restructure the 
> product so that it is a stand-alone operation and go with the database 
> inside of REALbasic. Besides, they might decide to go multi-user with 
> it after all.



More information about the Valentina mailing list