Re: Software needed
"Document Management Software" is a little vague. What do you want it to do? In general though, when someone says "content management" and "Python", the general response is Zope, usually with Plone on top. -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows Cmd.exe Window
Giles, you keep mentioning syntax errors as the (/a) cause of the problem. I suggest you avoid such problems, so that the import sethook approach, et al. will actually work. The easiest thing to do is to run PyChecker on your script prior to executing it. PyChecker will catch your syntax errors (and a whole host of other things, some of which are actual problems, some not) and let you know where they are. With that simple bit of testing, the other approaches that rely on a syntactically-correct script will work, because you will have corrected the syntax errors. You *will* have corrected the syntax errors, right? :) -- http://mail.python.org/mailman/listinfo/python-list
Re: suggestions invited
Reasonable enough. As per Mike's suggestion below, building a few web pages to document the apps is a good start. To expand on that idea, you could write daemons/cron jobs, perhaps in Python if Python runs on OS/400, that monitor each app's status and log that information to the web server. You could then write a web application that takes the monitoring data and formats it appropriately for human consumption. Perhaps an RSS or Atom feed for each application's status. I don't know anything about OS/400, but if it has a tool similar to syslog, you could configure the application hosts to report their status to a remote syslogd, perhaps on your web server, and parse the log file for the status data. -- http://mail.python.org/mailman/listinfo/python-list
Re: suggestions invited
As Konstantin alludes, your request is not specified clearly enough. In all-caps you write "APPLICATION MONITORING SYSTEM", yet your only use-case is "it lets the it employee enter the name of the application and gives him all the details about it", where "the details are ... " a bunch of fields that don't look to be changing very often, if ever. If you want to *monitor* the current status of these applications, then you have a reasonable project. Otherwise, your specifications as written lead to text files, or perhaps a small 3-ring binder with descriptions of each application neatly typed (why waste electricity?). So, please expand your question, and we'll try to help. -- http://mail.python.org/mailman/listinfo/python-list
Re: MS SQL Server/ODBC package for Python
> > Next I modified the benchmark to reflect my particular circumstances > > more accurately (?Maybe? Comments invited). I changed the query to > > one of the queries in regular use in my application. This query > > selects 26 columns from 3 joined tables, with a where clause "where > > f476 = ?", and I provide the missing value as a tuple in the execute > > statement. Note that, as I mentioned in my reply to M-A, the f476 > > field is not indexed, and is a long varchar. Again, the system is > > bought, so I have no control over the schema. ;) > > > > The other change I made was to reduce the number of iterations from 100 > > to 10. Since there are 128000 records in the main table, the wait for > > 100 iterations was too long for my patience. Under these > > circumstances, mx.ODBC's numbers are 188.49 seconds and 377.56 seconds > > respectively, and adodbapi's times are 111.15 seconds and 223.55 > > seconds respectively. > > Just curious: are you timing just the time it takes to > complete the .execute() or do you also fetch the complete > result or only part of it ? > I have included the .fetchall() in the loop, yes. The only other change I made to the benchmark is to use ODBC.Windows.DriverConnect rather than .Connect, as that's what I'd used before in my application. Is there a difference between the two, other than the argument syntax? > The mxODBC 2.0 release fetches this number after every .execute(). > If adodbapi avoids this (which we'll also integrate into mxODBC 2.1), > then this would explain the differences you see. > I look forward to retesting with 2.1 -- I'm curious to see what differences arise. > Another reason could indeed be related to the longvarchar > field: these fields are fetched in multiple chunks if the > ODBC driver doesn't provide proper size information - each > of these chunks will require a network access which slows > down the data fetching. The datum in the field is uniformly short, 8 characters or less. It's actually our internal identifier. Again, I'd use a varchar and index the field if I had control over the schema. However, the small size of the datum argues against multiple chunks, unless the default chunk size is really small. > > Since mxODBC supports Unicode, but defaults to returning > 8-bit strings, it is also possible that your longvarchar > column is sent as Unicode and has to be converted to > an 8-bit string first. Thus, allowing mxODBC to return Unicode > could make a difference as well (see the docs on how this is > done). I'll take a look into this, as I have a vague memory of adodbapi returning Unicode by default. > Note that it often also pay off checking the ODBC driver > settings, esp. if you have a networked setup - ODBC drivers > often pre-fetch result sets and changing the defaults they > use for this can make a huge difference in response times. > > Unfortunately, mxODBC doesn't have control over these > settings and there's no standard for them, so you'll > have to check the ODBC driver documentation for details > on the best settings can be found and set. I'll have to dig into this. There don't seem to be too many directly available settings in ODBC Administrator, but there seem to be some spots for inserting settings directly into a command line, so I'll need to dig up the Sybase documentation on what's possible. > > Regards, > -- > Marc-Andre Lemburg > eGenix.com Thank you very much for your patience and insight. Cheers, ---Peter Herndon -- http://mail.python.org/mailman/listinfo/python-list
Re: MS SQL Server/ODBC package for Python
I switched around the order, both in the actual application and in my tests as replied to Francois Lepoutre above. Results were consistent, after the first run of any given test, which unsurprisingly took a bit longer. -- http://mail.python.org/mailman/listinfo/python-list
Re: MS SQL Server/ODBC package for Python
:) Knock away, as my info isn't scientific anyway. In my case, ASA is *not* local. The db is running on a 500MHz x 2 server with 768MB RAM, over 100BaseT connection. That same server is also running the MSSQL instance, and IIS. Running your benchmark, I ran into a couple of interesting points. Using mx.ODBC, my times were 0.54 seconds and 6.56 seconds respectively, while using adodbapi my results are 3.55 seconds and 25.9 seconds respectively. mx.ODBC is faster with the simple query you provide. Next I modified the benchmark to reflect my particular circumstances more accurately (?Maybe? Comments invited). I changed the query to one of the queries in regular use in my application. This query selects 26 columns from 3 joined tables, with a where clause "where f476 = ?", and I provide the missing value as a tuple in the execute statement. Note that, as I mentioned in my reply to M-A, the f476 field is not indexed, and is a long varchar. Again, the system is bought, so I have no control over the schema. ;) The other change I made was to reduce the number of iterations from 100 to 10. Since there are 128000 records in the main table, the wait for 100 iterations was too long for my patience. Under these circumstances, mx.ODBC's numbers are 188.49 seconds and 377.56 seconds respectively, and adodbapi's times are 111.15 seconds and 223.55 seconds respectively. My first wall-clock impressions are obvious exaggerations of reality, for which I duly apologize to all. However, adodbapi did prove to be faster in my admittedly very wacky common use case. Slower to connect, but faster to run a substantial query. Comments? Questions? Suggestions for improvement? -- http://mail.python.org/mailman/listinfo/python-list
Re: MS SQL Server/ODBC package for Python
Marc-Andre, I apologize for knocking against something that is part of your livelihood, I hadn't thought about that aspect before I posted. In my experience though, adodbapi was much faster. However, I have done no benchmarks, my situation is likely pathological, and I wouldn't be able to build objective benchmarks anyway, so take it with a huge grain of salt. For what it is worth, my experience is as follows: Using a PIII 550MHz, 256MB RAM, running WinNT 4.0 and Python 2.3.4 and connecting to a Sybase Adaptive Server Anywhere 8.0 database, mx.ODBC took approximately 8 wall-clock seconds to connect, while adodbapi took about 2 seconds to connect. That timing is a guesstimate on my part, based on me counting. The only thing changed in the script was the driver import and the connect string. Likewise, a query that would need to search a table with a full data scan on the columns in the where clause (vendor doesn't believe in indexes), where the table has 20k - 30k rows, takes 30-60 seconds using mx.ODBC versus 15-30 seconds using adodbapi. A different application, connecting to MSSQL2K, also exhibited similar tendencies. mx.ODBC took a bit longer to connect than adodbapi, though the differences were *much* smaller. Not measurable by guesstimation, but a tad longer. Again, this is just my experience, and my situation is not likely to match others'. Given other circumstances, I would expect the results to differ, and I encourage the original poster to test all possible solutions to find the one that best fits his needs. ---Peter Herndon On 4/15/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Peter Herndon wrote: > > Another option is adodbapi, which in my experience is much faster than > > mx.ODBC. > > Much faster ? > > See > http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/reskit/iischp7.mspx > and scroll down to Table 7.1: > > Table 7.1 TPS (transactions per second) Per Number of Threads by MDAC > Technology > Threads 1 2 5 10 20 50 > ODBC 66.37 146.28 350.46 626.76 900.24 859.91 > OLEDB 67.30 141.92 326.19 590.57 794.91 715.78 > OLEDB 2.0 61.73 126.93 297.29 506.75 575.35 526.61 > ADO 2.0 51.24 108.12 240.91 377.30 361.26 310.34 > > > You can find it at http://adodbapi.sourceforge.net , and it > > is Windows-only. There's also http://pymssql.sourceforge.net, which is > > cross-platform using FreeTDS and unixodbc on *nix. I haven't any > > experience with it, though. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Apr 15 2005) > >>> Python/Zope Consulting and Support ...http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ > > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > -- http://mail.python.org/mailman/listinfo/python-list
Re: MS SQL Server/ODBC package for Python
Another option is adodbapi, which in my experience is much faster than mx.ODBC. You can find it at http://adodbapi.sourceforge.net , and it is Windows-only. There's also http://pymssql.sourceforge.net, which is cross-platform using FreeTDS and unixodbc on *nix. I haven't any experience with it, though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which is easier? Translating from C++ or from Java...
If you have three different implementations, and can read all three of them well enough to understand the code, use all three. If you are going to port software from one language to another, and want to reimplement it properly in your target language, you won't be porting word-for-word anyway. So use all three sources to find out what the problems were in the domain, and how they each solved them. Using that knowledge, figure out the best way to tackle those same problems in Python -- if those problems even exist. -- http://mail.python.org/mailman/listinfo/python-list
