Hello Rick, Thanks for the clarification. This really helped me a lot. I;m trying to do a mobile client synchronizing data with a server side DB. Yeah I think I saw it in a forum somewhere. I come across it I will let you know.
Thanks again. Best, Chux On Fri, Apr 11, 2014 at 9:41 PM, Rick Hillegas <[email protected]>wrote: > Hi Chux, > > The default (and maximum) size for a CLOB is 2,147,483,647 characters. See > http://db.apache.org/derby/docs/10.10/ref/rrefclob.html. If you have > found a place in the documentation where some other limit is stated, could > you let us know where that is so that we can correct that misleading > statement? > > Thanks, > -Rick > > > On 4/10/14 9:09 PM, Chux wrote: > >> Awesome insights guys, thanks for all your help. >> >> BTW, I could not access the online documentation for some reason. >> Although I read somewhere that 64k is the maximum size you can allocate a >> clob on embedded mode. Is this correct? I would like to know what the limit >> is. >> >> variable clob(64 K) >> >> Thanks, >> Chux >> >> >> On Thu, Apr 10, 2014 at 5:32 AM, Dag H. Wanvik <[email protected]<mailto: >> [email protected]>> wrote: >> >> >> On 09. april 2014 17:51, Rick Hillegas wrote: >> >> On 4/8/14 2:00 AM, Chux wrote: >> >> Hey Dag, >> >> Thanks for your insight. >> >> I'm using this as an embedded DB in a Java FX desktop >> application. This is a dumb question but would you >> recommend shutting down the database ever after a >> transaction? Like after you create a record then you shut >> it down after commit. >> >> Depends on the application. If the database holds some kind of >> infrequently referenced metadata, so that say, it is only >> queried or updated once a day, then you could consider an "on >> demand" model where the database is booted for each >> query/update, then the query results are returned, then the >> database is shut down so that it doesn't consume any >> resources. The big extra cost of an "on demand" database would >> be this: query/update time would be substantially longer >> since every query/update involves booting the database, >> compiling the query/update, and gracefully closing the >> database; that cost is on top of the steady-state cost of >> running a pre-compiled query/update. >> >> In such a scenario one might want to shut down the engine, too, >> not just the database. >> Note that shutting down the database will resources, but if the >> engine is still running, one can further release resources by >> shutting that down as well. >> >> Cf. >> http://db.apache.org/derby/docs/10.10/devguide/tdevdvlp20349.html >> (engine shutdown) >> and >> http://db.apache.org/derby/docs/10.10/devguide/tdevdvlp40464.html >> (shutdown database) >> >> Thanks, >> Dag >> >> >> >> >> >> Hope this helps, >> -Rick >> >> >> Best, >> Chux >> >> >> >> On Tue, Apr 8, 2014 at 12:32 AM, Dag H. Wanvik >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> >> <mailto:[email protected]>>> wrote: >> >> >> On 06. april 2014 21:02, George Toma wrote: >> >> Hi Chux, >> >> In my opinion the example from app. referred at >> commit the >> transaction OR close the connection ( a connection >> could be >> transacted too ), and not to shutdown the db. If >> the business >> rule specifies that the db. needs to be shutdown >> when the app. is >> shutdown, then so be it. >> >> Normally the db is not shutdown, not even when the >> app is down. >> >> >> This is true for a client/server application. For use with >> embedded Derby, one would normally close down the >> database (and >> the database engine) before exiting the application. >> If one >> neglects to do so, >> one would see longer start-up times as Dyre indicated. >> >> Thanks, >> Dag >> >> >> >> Cheers, >> George >> On Sunday, April 6, 2014 7:14 PM, Chux >> <[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]>> >> wrote: >> Hello guys, >> >> I read in a sample app that you've got to shutdown >> a database. I >> was just confused if you need to shut it down on >> every connection >> transaction or just shut it down on application >> close, in my case >> a desktop applicaiton. >> >> Best, >> Chux >> >> >> >> >> >> >> >> >
