Hi everybody,
funny enough, as a newbie to VW I really find it hard to understand how StORE treats my SQLServer; so please help or explain, if you know how to do it smoothly: On Store.DbRegistry installDatabaseTables VW asks me for a connection - so I give it an ODBC datasource as environment and BERN as login and as tableowner. The datasource points to some empty DB on SQLServer. When it asks if to create a new account I say "No" as BERN account already exiss on my SQLServer. Then it additionaly asks for the directory where the datafiles are stored. Why is that? What has StORE to do with creating data files? Well - I typed the path into the dialog field and StORE created TWO NEW DATABASES (NEWBERN 1 and 2) instead of simply creating tables within the given database. This appears to be hard coded as "tablespace" and even as "filename" in several places. This rises several questions which I couldn't yet answer myself: 1) Does StORE use the given ODBC environment at all? 2) Is it at all possible (without programming ;-) to install the StORE tables into a given database? Is it intended? 3) Is it intended to hold several StORE databases in parallel on the same SQLServer? If not which code do I need to provide to use StORE properly from point of view of DB administration? (IMHO the described isn't proper behaviour). Thanks for any hint. It will be heartily wellcomed. Thomas Schrader -- mailto thomas j schrader at web de ____________________________________________________________________ Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
<Sigh>
I think that what's going on there is that it's trying to store LOBs separately from the rest of the data, presumably as an optimization so that it could be put, for example, on a different physical disk. This probably made reasonable sense on Oracle 7 in the early 90's, but I suspect is not the most useful thing to do right now, and especially not to hard-code it, as it has been at the moment. I don't think it would be easy to get it set up the way you want it right now, although if you can set your database up so that it can use table names qualified as NEWBERN1.TABLE.FIELD and NEWBERN2.TABLE.FIELD and skip the "install physical tables" setup, then you should at least be able to get it working on the database that you want it to use. I don't know offhand if SQL Server will let you use those sorts of qualifiers without having them correspond to actual physical databases. So, to answer the questions 1) yes, it uses the ODBC environment, but it qualifies the tables as above 2) if you can make sql server accept those qualified names but have the tables where you want, then yes, otherwise, probably not 3) Um, I think we'd obviously like to be able to support multiple store databases on a sql server installation. I think you could manage that by having different table owners, but I haven't actually tried it myself. Sorry not to have any better answers for you. At 03:58 PM 12/7/2008, Thomas Schrader wrote: Hi everybody, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |