 | |
#111
 
| |||
| |||
|
Re: Considerations migrating from Access 97 mdb to Access 2003 (or up)? -
01-07-2011
, 08:11 PM
|
On 1/4/11 8:51 PM, David-W-Fenton wrote: Ryan<Mindflux98 (AT) gNOSPAMPLEASEmail (DOT) com> wrote in news:ifu3vo$tj2$1 (AT) news (DOT) eternal-september.org: Forms were positioned fine for 97-2003, once we went to ribbon style it apparently changed all that. What I mean is that you are apparently just using Ctrl-S to position your forms, which is not what I'd consider a "correct" method for positioning forms. Your alternatives for positioning forms are: 1. set the AutoResize and AutoCenter properties. 2. run them maximized. 3. use Stephen Lebans form resizing/positioning code to get full pixel-level control of where your forms will appear. All of these things will avoid any problems with different toolbar/ribbon sizes. I don't even know what Ctrl-S is? I've never used it in form design? |
SAVE toolbar button.
Quote:
|
Most of my forms are maximized, there are a few modal forms but other then that nearly everything is maximized and as I stated the ribbon covers up several buttons on one of my primary(most used) forms. |
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#112
| |||
| |||
|
|
To add to it, I guess if Ctrl-S is just saving the form after I've positioned it, yeah I guess that's accurate. I just hit the "Floppy" icon... same difference in essence. |
problems. For instance, if I save a form on my other monitor, it
will run entirely off-screen for my users who don't have two
monitors.
Quote:
|
As stated before, I believe most (if not all) of my forms are already maximized.. or unless that's another code property I'm not aware of? The application is designed to run in full screen and most of the forms designed around that concept. |
AutoCenter for positioning of all forms. In the few cases where I
have wanted really strict control over positioning, I've used
Stephen Lebans's code. It's not without its issues, since different
"skins" can cause title bars to be different heights, so it's not
straightforward to size things with it.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#113
| |||
| |||
|
|
Finally, ADP can be used _only_ with the Microsoft SQL Server database engine, unlike the recommended method of linked tables in ODBC (which never stopped being supported, has always had continuing development, and is again recommended by the Access team at Microsoft as the method of choice) which can be used with any ODBC-compliant database, and either Jet or ACE local tables, along with the server tables, if that is convenient, and it often is. |
using ODBC linked tables using the new SQL Server native ODBC
client, which in my experience, is blazingly fast (in comparison to
the older SQL Server ODBC drivers). It seems obvious to me that MS
has put a lot of effort into making a superior ODBC driver for SQL
Server to go with their new SQL Server version, which should tell
you something about which technologies they consider to be "the
future."
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#114
| |||
| |||
|
|
ADP can be used with -any- database engine that supports ODBC through the use of linked server. I use linked servers extensively. |
You are just hysterically funny, Aaron.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#115
| |||
| |||
|
|
Ryan <Mindflu... (AT) gNOSPAMPLEASEmail (DOT) com> wrote innews:ifba84$f4b$1 (AT) news (DOT) eternal-september.org: On 12/25/10 5:32 PM, David-W-Fenton wrote: Ryan<Mindflu... (AT) gNOSPAMPLEASEmail (DOT) com> *wrote in news:if14sk$1cq$1 (AT) news (DOT) eternal-september.org: On 12/23/10 7:49 PM, David-W-Fenton wrote: Ryan<Mindflu... (AT) gNOSPAMPLEASEmail (DOT) com> * wrote in news:if0pln$vpt$1 (AT) news (DOT) eternal-september.org: On 12/23/10 5:42 PM, Rick Brandt wrote: Ryan wrote: Did more debugging (not sure why I'm doing this on vacation) and it turns out my passthroughs are dying because of an ODBCDirect workspace, I guess 2007+ doesn't support this anymore. Any suggestions on a quick way to re-write that code in ADO or other? I have never used ODBCDirect. *All I have ever used is DAO. IT's part of a DAO Workspace, no longer supported in 07 and up. I never understood the point of ODBCDirect. It seemed to me like an early effort to do what ADPs did, which was to avoid Jet entirely, and that was a stupid idea, so it seems to me that the point of ODBCDirect is not too compelling, either. What's wrong with plain ODBC? I'm not sure, honestly. As I said in another post this is code I 'inherited' as we bought the rights to use the source from the company who sold the product and it's undergone years of development at my hands. The parts that haven't changed (such as this ODBCDirect issue I'm facing) are probably snippets of code I've never even glanced at. The primary question is how do I re-write this to work in ADO (which I know you are not a fan of). I don't see why you think the answer to replacing ODBCDirect is to use ADO. It's deprecated, it's dead, it's got no future. Unless ODBCDirect did things that only ADO does, I'd not even consider trying to rewrite with ADO -- it just makes no sense, as it has no future in Access. Microsoft is the one that suggested converting it to ADO, not me. How recent is the documentation that suggested that? I think it very likely it's something that dates from the "ADO wars" period, when MS was incorrectly pushing ADO for use with Access. What I did is I took the DAO Workspace which was depreciated and made a querydef to run the pass-thru. (So this is now DAO/ODBC, in essence) DAO is not deprecated. It is in live development, with new versions coming out with each new version of ACE/Jet. That contrasts to Classic ADO, which has not been updated for a long time, and never will be (because it has been replaced with ADO.NET, which does not work with Access, and likely never will, at least not until Access is .NET-compatible). [] The pass-through tables are local to the MDE so a DAO recordset should do just fine there, but the creation of the remote temp table has me a bit boggled. I just don't see why plain ODBC and standard passthrough queries won't do the job. But then, I'm not looking at the actual code. I would definitely recommend against spending time trying to convert it to ADO, unless I'd already determined that this was a requirement. I miss-read the code and thought it was making a remote table via the ODBC Direct workspace. *I've since then transformed a couple lines of code to run everything through a querydef instead. *The thing I am concerned with here is front end bloat though. You mean you're writing a QueryDef each time you use it? Likely completely unnecessary. Post your code and maybe somebody can suggest a fix that doesn't require rewriting and saving it each time. Do you know about temporary QueryDefs? If you supply no name when you open it, it will be discarded when you close it (I forget the details -- it's something I have never had any cause to do). I do believe that temporary QueryDefs do still contribute to front-end bloat, but not very much. I'd still want to use some other approach if it were my app. -- David W. Fenton * * * * * * * * *http://www.dfenton.com/ contact via website only * *http://www.dfenton.com/DFA/ |
#116
| |||
| |||
|
|
On Sun, 2 Jan 2011 13:47:42 -0800 (PST), "a a r o n . k e m p f @gmail.com [MCITP: DBA]" <aaron.ke... (AT) gmail (DOT) com> wrote: re: microsoft hasn't updated ADO.. you are flat out wrong. Microsoft released version 6.0 of ADO with Microsoft Vista. Based on version numbers yes ADO 6.0 did some with Windows Vista.Practically there is no real difference between ADO 6.0 in Vista, 6.1 in Windows 7 and 2.8 which comes with Windows XP. "What Is the Difference Between Windows DAC and MDAC? Windows Data Access Components (Windows DAC) 6.0 is the version of the data access technologies—ADO, OLE DB, and ODBC—included in the Windows Vista operating system. Microsoft Data Access Components (MDAC) includes earlier versions of the same technologies, and version 2.8 was included in Windows XP and Windows Server 2003. There is also a redistributable version, MDAC 2.8 SP1, which should only be used with Windows 2000. Windows DAC includes some changes to work with Windows Vista, but is almost entirely functionally equivalent to MDAC 2.8."http://msdn.microsoft.com/en-us/library/ms692877%28v=VS.85%29.aspx And meanwhile, what you guys call 'DAO' is now called something else. Correct. *The updated version is ACE. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files * updated seehttp://www.autofeupdater.com/ |
#117
| |||
| |||
|
|
ADPs are no longer recommended by the Access team at Microsoft. *LinkedODBC tables are the approach they recommend (and, contrary to Mr. Kempf's implication, there's only one copy of the table itself, which is in the server DB), Using ODBC and linking the tables, the server DB need only be ODBC-compliant, and is not limited to Microsoft SQL Server as is ADP. I am not surprised if Mr. Kempf has never encountered a business which standardized on a different DB than Microsoft SQL Server -- his limited exposure to the Real World of Databases is obvious from his posts). *Larry Linson, Microsoft Office Access MVP "a a r o n . k e m p f @gmail.com [MCITP: DBA]" <aaron.ke... (AT) gmail (DOT) com wrote in messagenews:f5eb1e23-41d3-40e5-ab5a-224efb83770c (AT) glegroupsg2000goo (DOT) googlegroups.com... anti-Access bigots? I'm not anti-Access. I'm against JET. Access kicks ass.. but Jet can lick my nuts. It's not reliable, it's not consistent.. It just doesn't work for any workload. Move to SQL Server and use Access Data Projects-- that is the way to simplify Access. *Have only ONE copy of tables / queries (on the db server where they belong). -Aaron |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.