Importing and modelling databases

[Bruno.Cossi]

Hi Lauchlan,

I see. Well, you can certainly close or hide all the other panes as well as the toolbars, which leaves you for the diagram itself the whole screen minus the title bar... not quite what you want, but as close as it gets!
No problem about NexusDB, as luck would have it I came across the Lite version only yesterday :-)

Happy to help!
Bruno

Hi Bruno.

By "floating out" I meant grabbing some handle and undocking the pane so it "floated" above the rest of the IDE, and then I would want to maximize that pane window to take the whole screen area. Basically I wanted some way to get the diagram view to (temporarily) take up the entire screen real estate, while I dragged things around.

Thanks for the tip with NexusDB - they brought out quite a few new product versions since I started with them and I guess I wasn't paying attention when they brought out an ODBC Lite version. Sounds like it would meet my needs!

Thanks!

Lauchlan Mackinnon

[Bruno.Cossi]

You're welcome!

As far as the feature requests go, the best way would probably be going to the Sparx Systems' home page and going to menu Interactive Sparx > Request a Feature.
Sparx (Sparxes?) seem to be reading the forum regularly and frequently answer questions here, but I am not sure if they can keep track of all the requests made here in the forum (just see how this little thread grew in the past half an hour :-) )

Hope this helps!
Bruno

Yep, that did the trick, thanks!

BTW, the couple of requests I had - like putting checkboxes on the list of tables to import; to provide a mechanism from importing from ADO and ADO.NET as well as ODBC, etc - should I log them or lob them to somewhere, or do Sparx monitor this web forum and take prompt and immediate action? <g>

[sargasso]

"ODBC is based on Call-Level Interface and was defined by the SQL Access Group. Microsoft was one member of the group and was the first company to release a commercial product based on its work (under Microsoft Windows) but ODBC is not a Microsoft standard (as many people believe)."

(http://burks.brighton.ac.uk/burks/foldoc/93/83.htm)

"ADO: Short for ActiveX Data Objects, Microsoft's newest high-level interface for data objects. ADO is designed to eventually replace Data Access Objects (DAO) and Remote Data Objects (RDO). Unlike RDO and DAO, which are designed only for accessing relational databases, ADO is more general and can be used to access all sorts of different types of data, including web pages, spreadsheets, and other types of documents.

Together with OLE DB and ODBC, ADO is one of the main components of Microsoft's Universal Data Access (UDA) specification, which is designed to provide a consistent way of accessing data regardless of how the data are structured."

(http://www.webopedia.com/TERM/A/ADO.html)

"The Microsoft® Open Database Connectivity (ODBC) interface is a C programming language interface that makes it possible for applications to access data from a variety of database management systems (DBMSs). The ODBC interface permits maximum interoperability — an application can access data in diverse DBMSs through a single interface. Furthermore, that application will be independent of any DBMS from which it accesses data."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/dasdkodbcoverview.asp

"ActiveX Data Objects (ADO) provides a high-level programming model that will continue to be enhanced. Although a little less performant than coding to OLE DB or ODBC directly,..."

(http://msdn.microsoft.com/data/DataAccess/mdac/default.aspx?pull=/library/en-us/dnmdac/html/data_mdacroadmap.asp&print=true#mdac%20technologies%20road%20map%20old_topic1)

and from the same page...

"ADOX: ADO Extensions for DDL and Security (ADOX) enables the creation and modification of definitions of a database, a table, an index, or a stored procedure. You can use ADOX with any provider. The Microsoft Jet OLE DB Provider provides full support for ADOX, while the Microsoft SQL OLE DB Provider provides limited support. No major enhancements are planned for ADOX in future MDAC releases;"

"ODBC: The Microsoft Open Database Connectivity (ODBC) interface is a C programming language interface that allows applications to access data from a variety of Database Management Systems (DBMS). Applications using this API are limited to accessing relational data sources only. ODBC will be available on the 64-bit Windows operating system."

Right now I can't see a really compelling reason for Sparx to move away from a stable industrywide interface that directly accesses RDBMS's to a generalised MS specific  interface that does not seem to have a clear future.

JM20CW
bruce

[Lauchlan_Mackinnon]

Right now I can't see a really compelling reason for Sparx to move away from a stable industrywide interface that directly accesses RDBMS's to a generalised MS specific  interface that does not seem to have a clear future.
bruce

I don't think I said ADO "instead of" ODBC, but rather ADO "as well as" ODBC. I don't see any compelling reason to drop ODBC support if they already have it.

In any case, the reason is the same reason why people in the industry always move on to the new/next standard - because MS decree it, and if you don't jump to follow, you get left behind. In this case, customers or potential customers like me who haven't used ODBC in years and now use ADO and ADO.NET regularly.

Also, with regard to the other links you posted, in my experience OLEDB is a LOT faster than ODBC, so there's a definite (end-user) gain in supporting that particular data access mechanism.

And my main reason for liking ADO in this context is not unbridled enthusiasm for the ADO framework, it's that it is very easy to configure an ADO connection string with the tools that every software development environment seems to offer. If MS or someone else had made the ODBC wizard a bit more intuitive and better documented I probably wouldn't care overly much.

The connection is being used, after all, to read the database structure once. If it takes a few seconds or a few minutes longer, it's probably not of all that much consequence.

Also, my recollection is MS developed ODBC in conjunction with a bunch of other participants in the software industry but it was always very much MS driving it and shaping the agenda as it suited them. I can't respond to your specific points as they seem to have gone off-screen while I'm writing my reply.

Lauchlan Mackinnon

[Lauchlan_Mackinnon]

Right now I can't see a really compelling reason for Sparx to move away from a stable industrywide interface that directly accesses RDBMS's to a generalised MS specific  interface that does not seem to have a clear future.

Also, I don't think ODBC accesses databases "directly". There  are native drivers for Oracle, SQL Server, etc, but IIRC ODBC is not such. ODBC AFAICR accesses the database server through a driver accessed through ODBC. There is a layer between the user and the database server. On the other hand, OLEDB presents a much thinner layer than ODBC, with corresponding speed increases.

Lauchlan Mackinnon

[sargasso]

IIRC,

ADO-->OLEDB-->nativedriver

ODBC-->native driver

that's all  I was saying, that ADO (not OLEDB) has the extra layer.  

My experiences actually differ in a few projects.  2 projects where ADO was dumped in favour of ODBC on performance grounds. One Delphi project using a distributed SQLServer 7 and one VS project where we wanted to hold conections to a (reasonably) local db open for considerable time.   Other projects ADO or ODBC gave the required performance - alternatives not investigated.


anyway as i said JM20CW

bruce

[mikewhit]

Or
YYURYYUBICURyy4me.
Mike.